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¶
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.
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.
