horizon/releasenotes/source/grizzly.rst
Akihiro Motoki 3aeb73c641 Move past release notes under doc/ to releasenotes/
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
2016-09-20 18:15:32 +09:00

11 KiB

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:

  1. For a non-malicious user these errors are almost 100% the result of misconfiguration and this makes debugging possible.
  2. A malicious user can make the exact same "unauthorized" requests via the CLI as they can via the dashboard; no special privileges are granted.
  3. 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.

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.