The Folsom release cycle brought several major advances to Horizon’s user experience while also reintroducing Quantum networking as a core piece of the OpenStack Dashboard.
With Quantum being a core project for the Folsom release, we worked closely with the Quantum team to bring networking support back into Horizon. This appears in two primary places: the Networks panel in both the Project and Admin dashboards, and the Network tab in the Launch Instance workflow. Expect further improvements in these areas as Quantum continues to mature and more users adopt this model of virtual network management.
By far the biggest UI/UX change in the Folsom release is the introduction of programmatic workflows. These components allow developers to create concise interactions that combine discrete tasks spanning multiple services and resources in a user-friendly way and with minimal boilerplate code. Within a workflow, related objects can also be dynamically created so users don’t lose their place when they realize the item they wanted isn’t currently available. Look for examples of these workflows in Launch Instance, Associate Floating IP, and Create/Edit Project.
Another cool new component is an interface designed for “browsing” resources which are nested under a parent resource. The object store (Swift) is a prime example of this. Now there is a consistent top-level navigation for containers on the left-hand pane of the “browser” while the right-hand pane lets you explore within those containers and sub-folders.
Some of the general areas of improvement include:
Due to the very late addition of floating IP support in Quantum, Nova’s integration there is lacking, so floating IP-related API calls to Nova will fail when your OpenStack deployment uses Quantum for networking. This means that Horizon actions such as “allocate” and “associate” floating IPs will not work either since they rely on the underlying APIs.
A number of the “index” pages don’t fully work with API pagination yet, causing them to only display the first chunk of results returned by the API. This number is often 1000 (as in the case of novaclient results), but does vary somewhat.
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 Folsom Horizon release should be fully-compatible with both Folsom and Essex versions of the rest of the OpenStack core projects (Nova, Swift, etc.). While some features work significantly better with an all-Folsom stack due to bugfixes, etc. in underlying services, there should not be any limitations on what will or will not function. (Note: Quantum was not a core OpenStack project in Essex, and thus this statement does not apply to network management.)
In terms of APIs provided for extending Horizon, there are a handful of backwards-incompatible changes that were made:
Overall, though, great effort has been made to maintain compatibility for third-party developers who may have built on Horizon so far.