Adds Grizzly release notes.
Fixes bug 1157348. Change-Id: Ic3a7725d4ef489033d98d48d21671b2d982def8e
This commit is contained in:
parent
8a6c81ad27
commit
1ae75986e4
276
doc/source/releases/2013_1.rst
Normal file
276
doc/source/releases/2013_1.rst
Normal file
@ -0,0 +1,276 @@
|
||||
========================
|
||||
Horizon 2013.1 "Grizzly"
|
||||
========================
|
||||
|
||||
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 resitricted 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 signficantly 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.
|
||||
|
||||
Easier Theming For Distros
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Many distros have policies of not modifying the source code for a package, and
|
||||
that made providing a custom theme or stylesheet for Horizon quite difficult.
|
||||
As such, new mechanisms for defining a custom theme path have been added so that
|
||||
it can be added to your local_settings file instead of having to alter any of
|
||||
the core OpenStack Dashboard files.
|
||||
|
||||
|
||||
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 appopriate 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.
|
||||
|
||||
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.
|
Loading…
Reference in New Issue
Block a user