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.
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.
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.
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.
Administrators now have the ability to migrate an instance off of its current host via the Admin dashboard’s Instances panel.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.