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