3aeb73c641
We are now publishing release notes through releasenotes/ (at http://docs.openstack.org/releasenotes/). On the other hand, we used doc/ for past release notes. It looks better to merge the past release notes to the new location. Change-Id: I7478e86600074bec9d8f2596c4be3c4b389ee7bb
275 lines
11 KiB
ReStructuredText
275 lines
11 KiB
ReStructuredText
============================
|
|
Grizzly Series Release Notes
|
|
============================
|
|
|
|
Release Overview
|
|
================
|
|
|
|
The Grizzly release cycle saw sweeping improvements to overall user experience,
|
|
huge stability improvements, lots of new networking, instance management and
|
|
image management features, a long-needed architectural clarification, and big
|
|
increases in community engagement! Read on to get the specifics.
|
|
|
|
Highlights
|
|
==========
|
|
|
|
New Features
|
|
------------
|
|
|
|
Networking
|
|
~~~~~~~~~~
|
|
|
|
Quantum added a huge number of new features in Grizzly, including L3 support
|
|
(routers), load balancers, network topology infographics, better compatibility
|
|
with Nova networking APIs (VNIC ordering when launching an instance; security
|
|
groups and floating IP integration) and vastly improved informational displays.
|
|
|
|
Direct Image Upload To Glance
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
It is now possible (though there are numerous deployment/security implications)
|
|
to upload an image file directly from a user's hard disk to Glance through
|
|
Horizon. For multi-GB images it is still strongly recommended that the upload
|
|
be done using the Glance CLI. Further improvements to this feature will come in
|
|
future releases.
|
|
|
|
Flavor Extra Specs Support
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
In Folsom, Nova added support for "extra specs" on flavors--additional metadata
|
|
which custom schedulers could use for appropriately scheduling instances. As of
|
|
the Grizzly release, Horizon now supports reading and writing that data on any
|
|
flavor.
|
|
|
|
Migrate Instance
|
|
~~~~~~~~~~~~~~~~
|
|
|
|
Administrators now have the ability to migrate an instance off of its current
|
|
host via the Admin dashboard's Instances panel.
|
|
|
|
|
|
User Experience Improvements
|
|
----------------------------
|
|
|
|
"Not Authorized" & Being Logged Out
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
A shocking number of the problems first-time deployers of OpenStack have can be
|
|
summarized as "I thought I set everything up, then I tried to log into the
|
|
dashboard and I was immediately logged back out." The root cause of this was
|
|
that in an effort to be as secure as possible any 401 or 403 response from
|
|
any service API was being treated the same as if it was an attempt to access
|
|
an unauthorized portion of Horizon, and the user was summarily logged out with
|
|
little to no information as to why.
|
|
|
|
In Grizzly we have instead chosen to improve this by treating service API
|
|
401 and 403 errors as slightly less severe than unauthorized access attempts
|
|
to restricted areas of Horizon. The reason for this is threefold:
|
|
|
|
#. For a non-malicious user these errors are almost 100% the result of
|
|
misconfiguration and this makes debugging possible.
|
|
#. A malicious user can make the exact same "unauthorized" requests via the
|
|
CLI as they can via the dashboard; no special privileges are granted.
|
|
#. API errors are generated by external systems not under the purview of our
|
|
project and while we should attempt to respect and take appropriate action
|
|
on those errors, we should not do anything drastic or even potentially
|
|
destructive because of them.
|
|
|
|
Going forward the user will not be logged out, but no information will be
|
|
populated on the page and they will be presented with error messages informing
|
|
them that they are unauthorized for the data they attempted to access.
|
|
|
|
Reorganizations
|
|
~~~~~~~~~~~~~~~
|
|
|
|
A couple of long-standing user confusions were fixed in Grizzly.
|
|
|
|
First off, the API Access panel (containing a user's API endpoints, rc files,
|
|
and EC2 credentials) was moved from Settings to the Access & Security section
|
|
of the Project dashboard.
|
|
|
|
Second, the Default Quotas and Services panels (which were both strictly
|
|
informational) were combined into tabs in a single System Info panel to make
|
|
it clear that these panels are thematically related, and to create a home for
|
|
informational-only displays like these.
|
|
|
|
One-click Floating IP Management
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
A common complaint from users was that associating a floating IP to an
|
|
instance involved numerous clicks and form selections for something that
|
|
the majority of users had no knowledge of and didn't care about. As such, a
|
|
one-click "simple" floating IP association option has been created. For
|
|
deployments which only have a single floating IP pool, this allows users to
|
|
ignore explicit floating IP management and just click a button to associate
|
|
or disassociate a floating IP with an instance.
|
|
|
|
Organized Images
|
|
~~~~~~~~~~~~~~~~
|
|
|
|
The Images table now has a new feature: predefined filters for seeing your own
|
|
images, images that have been shared with you, or public images. This makes
|
|
finding the image you're looking for a great deal easier and more pleasant.
|
|
|
|
Security Group Rule Editing Improvements
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The security group rule editing experience has always been inherently very
|
|
complicated simply given the number of options and the very technical terms
|
|
involved. Moreover, the combined table-plus-form approach the OpenStack
|
|
Dashboard had taken only made the UX more frustrating for an already difficult
|
|
area.
|
|
|
|
In Grizzly this has all been reworked to be significantly simpler, and to
|
|
provide as much contextual help and streamlining as possible.
|
|
|
|
Icons!
|
|
~~~~~~
|
|
|
|
In an effort to make the dashboard more at-a-glance usable, we've added icons
|
|
to most of the common action buttons throughout the dashboard.
|
|
|
|
"More Actions", More Better
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Lots of feedback came in that the "more actions" dropdown menu (for tables with
|
|
numerous actions available on each row) was confusing to new users and/or
|
|
difficult to click.
|
|
|
|
We've now improved it so that the button to open the menu is clearly labeled
|
|
and the hitbox for clicking it is significantly larger.
|
|
|
|
|
|
Community
|
|
---------
|
|
|
|
Docs, docs, and more docs!
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Large amounts of new documentation was added during the Grizzly cycle, most
|
|
notably are sections documenting: all of the available settings for Horizon and
|
|
the OpenStack Dashboard; security and deployment considerations; and deeper
|
|
guides on customizing the OpenStack Dashboard.
|
|
|
|
IRC Meeting
|
|
~~~~~~~~~~~
|
|
|
|
During the Grizzly cycle we started holding a weekly project meeting on IRC.
|
|
This has been extremely beneficial for the growth and progress of the project.
|
|
Check out the `OpenStack Meetings wiki page`_ for specifics.
|
|
|
|
.. _OpenStack Meetings wiki page: https://wiki.openstack.org/wiki/Meetings#Horizon_team_meeting
|
|
|
|
|
|
Under The Hood
|
|
--------------
|
|
|
|
Legacy Dashboard Names & Code Separation
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Very early in the Grizzly cycle we took the opportunity to do some longstanding
|
|
cleanup and refactoring work. The "nova" dashboard was renamed to "project" and
|
|
the "syspanel" dashboard was renamed to "admin" to better reflect their
|
|
respective purposes.
|
|
|
|
Moreover, a better separation was created between code related to the core
|
|
Horizon framework code (which is not related to OpenStack specifically) and
|
|
the OpenStack Dashboard code. At this point *all* code related to OpenStack
|
|
lives in the OpenStack Dashboard directory, while the Horizon framework is
|
|
completely agnostic and is a reusable Django app.
|
|
|
|
Object Storage Delimiters and Pseudo-folder Objects
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
When Horizon's object storage interface was first added, Swift's documentation
|
|
recommended adding 0-byte objects with a special content type to denote
|
|
pseudo-folders within a container. They have since decided that this is not the
|
|
recommended practice, and that pseudo-folders should only be demarcated by
|
|
a delimiting character (usually "/") in the object name.
|
|
|
|
Horizon has been updated under the hood to use this method, which should bring
|
|
it better into line with how most deployments are using their object storage.
|
|
|
|
|
|
Other Improvements and Fixes
|
|
----------------------------
|
|
|
|
* Support for Keystone's PKI tokens.
|
|
|
|
* Flavor editing was made significantly more stable.
|
|
|
|
* Security groups can be added to a running instance.
|
|
|
|
* Volume quotas are handled by the appropriate service depending on whether
|
|
or not Cinder is enabled.
|
|
|
|
* Password confirmation boxes are now validated for matching passwords on
|
|
the client side for more immediate feedback.
|
|
|
|
* Numerous fixes to display more and better information for instances and
|
|
volumes in their overview pages.
|
|
|
|
* Improved unicode support for the Object Storage panels.
|
|
|
|
* Logout now attempts to delete the token(s) associated with the current
|
|
session to avoid replay attacks, etc.
|
|
|
|
* Various fixes for browser compatibility and rendering.
|
|
|
|
* Many, many other bugfixes and improvements. Check out Launchpad for the full
|
|
list of what went on in Grizzly.
|
|
|
|
|
|
Known Issues and Limitations
|
|
============================
|
|
|
|
Editing a Flavor Which Results In An API Error Will Delete The Flavor
|
|
---------------------------------------------------------------------
|
|
|
|
Due to the way that Nova handles flavor editing/replacement it is necessary
|
|
to delete the old flavor before creating the replacement flavor. As such,
|
|
if an API error occurs while creating the replacement it is possible to
|
|
lose the old flavor without the new one being created.
|
|
|
|
Creating Rich Network Topologies
|
|
--------------------------------
|
|
|
|
Due to several Quantum features landing very late in the Grizzly cycle, it
|
|
is not possible to create particularly complex networking configurations
|
|
through the OpenStack Dashboard. These features will continue to grow
|
|
throughout future releases.
|
|
|
|
Loadbalancer Feature
|
|
--------------------
|
|
|
|
The Loadbalancer feature landed in the 11th hour for both Quantum and Horizon
|
|
and, though we did our best to test it, may still contain undiscovered bugs. It
|
|
is best considered a "beta" or "experimental" feature for the Grizzly release.
|
|
|
|
Quantum Brocade Plugin Not Compatible
|
|
-------------------------------------
|
|
|
|
The Brocade plugin for Quantum does not support key features of the floating
|
|
IP addresses API which are considered central to Horizon's functionality. As
|
|
such, it is not compatible with the Grizzly release's Quantum integration.
|
|
|
|
Deleting large numbers of resources simultaneously
|
|
--------------------------------------------------
|
|
|
|
Using the "select all" checkbox to delete large numbers of resources via the
|
|
API can cause network timeouts (depending on configuration). This is
|
|
due to the APIs not supporting bulk-deletion natively, and consequently Horizon
|
|
has to send requests to delete each resource individually behind the scenes.
|
|
|
|
Backwards Compatibility
|
|
=======================
|
|
|
|
The Grizzly Horizon release should be fully compatible with both Grizzly and
|
|
Folsom versions of the rest of the OpenStack core projects (Nova, Swift, etc.).
|
|
While some features work significantly better with an all-Grizzly stack due
|
|
to bugfixes, etc. in underlying services, there should not be limitations
|
|
on what will or will not function.
|
|
|
|
Overall, great effort has been made to maintain compatibility for
|
|
third-party developers who may have built on Horizon so far.
|