We had several very productive Horizon sessions at the summit last
week. Thanks to everyone who was able to contribute, especially the
folks from the Keystone project for the combined session. A summary of
the discussions and outcomes:
== Project Organisation ==
We will be formalising our guidance and processes around project core
team members; how we choose them and their responsibilities once in
the core team. Further messages around those issues will follow this
We also discussed how to improve our use of reno, most notably about
ensuring that reno is included in patches that need it (most
importantly for upgrade information). We considered a gerrit bot that
would monitor large patches to prompt the patch author that a reno
component should be included in the patch; we just need a volunteer to
write the bot :-)
The use of reno is important to both notify operators and deployers of
big (or breaking) changes in Horizon, but also to ensure that that
information is included in stable branch backports. Please keep that
in mind when reviewing patches.
We talked through some improvements to our documentation: most notably
that we need better docs for testing setup and enabled files for
components. We are starting to get some higher-level documentation
== Testing ==
Our Selenium tests are still broken, but Timur Sufiev has a number of
thoughts on how to address the issues (which all stem from breaking
changes introduced in recent releases of both selenium and firefox).
We also discussed ways to improve reliability (and possibly
performance) of the tests, most likely by using a single browser
Matt Borland also offered to examine the current selenium test suite
to determine which tests are unnecessary or out of date, and also to
look into which UI areas still have no coverage.
Related to testing is the migration from runtests.sh to tox, which is
90% complete (runtests.sh now generates a warning that it is
deprecated). Rob Cresswell is working through the last remaining bits
of functionality to allow that transition to complete.
== Keystone cross-project session ==
We met with the Keystone folks to talk through the current areas of
pain. We determined a number of points of action, one of which
(Horizon no longer revoking tokens) is already up as a patch, thanks
Eric Peterson! The two projects will also continue to look into
federation, default project roles, policy issues, k2k and project
We've started up a regular weekly meeting to continue the discussion
around Keystone and Horizon integration issues. The kickoff for these
meetings will be 8th November 2000UTC in #openstack-meeting-cp
(more detail in https://etherpad.openstack.org/p/ocata-keystone-horizon)
== AngularJS ==
We discussed the use of generic service proxies (as opposed to going
through the python clients) and agreed that they could be of use where
it is appropriate (where the python client adds no value). For a lot
of the core services those python clients do add value (especially
when microservices come into the picture - more on that below). We
ended up on the fence about including a generic proxy in Horizon, but
it could offer a good benefit to plugin authors who would then not
need to each write their own.
There was a general consensus to avoid continued refactoring for this
Ocata release, and focus on implementing the replacement panels
instead. To that end we identified a number of in-flight patches and
discussed priorities for the release.
The Launch Instance workflow still needs refinement (absent
functionality and lack of extensibility in a couple of areas) so it
was decided that the deprecation of the Django-based workflow would be
put on hold until the end of Pike. The Django implementation of the
Swift UI is being removed in Ocata though, and David Lyle has a patch
in the works to do that.
We intend to land ui-router support in Ocata-1 to support the Swift UI
and any other view that needs nested routing. Additionally, the
removal of scope usage in actions services should be completed in
Ocata-1 to lay down the pattern for follow-on panel work.
(more in https://etherpad.openstack.org/p/horizon-ocata-angularjs)
== Other bits ==
Eric's going to Make Quotas Great Again, and we're all excited. Some
Glance v2 cleanup (including a view filtering issue for admin users).
We discussed using websockets for view updates (eg. instances list)
but agreed that having Horizon listen to the flood of updates from
services would not be sensible, and rather we would continue to poll
and perhaps use Searchlight as a filtering intermediary.
(more in https://etherpad.openstack.org/p/horizon-ocata-cross-project)
== Microversions ==
We discussed how we would approach microversions, and have a potential
first implementation in mind - instance descriptions (already captured
as a blueprint, though that will be revised in light of the
The key take-away here is that we will always target the maximum
version supported by a given service. If a service says it supports
"2.90" but we happen to know that microversion "2.15" supported a
particular feature, we will not go through all the shenanigans
necessary to actually support it (ie. creating a specific client
connection at that version in order to use that feature).
We will maintain a mapping of a sensible-to-Horizon capability name
(eg. "nova:instance-description") to a range of versions specified
like requirements.txt (eg. ">2.19,!=2.50,<2.90") which will be
resolved with the maximum version supported by the service in question
(retrieved from the service) to result in a boolean True/False. This
mapping will then be used to toggle features in the UI.
(more on that plan in https://etherpad.openstack.org/p/horizon-ocata-priorities)
== Priorities ==
Since Ocata-1 is so soon (Nov 14-18, two weeks away) we will attempt
to get only in-flight patches into the codebase now, and those patches
won't be major end-user features. The panel re-works (identity panels,
flavors, volumes, etc.) will be tackled in Ocata-2 and -3.
That's still a large amount of work, so we'll see how we go.
(more in https://etherpad.openstack.org/p/horizon-ocata-priorities)
== Blueprints clean-up ==
In our final Horizon session of the summit we re-visited some of the
discussions above, but also we performed a thorough, and somewhat
ruthless review of open blueprints. This resulted in us closing over
100 blueprints. If you believe your blueprint was closed in error,
please get in touch!
OpenStack Development Mailing List (not for usage questions)