Hi folks, 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 one. 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 plugins. Also, we still don't generate docs for our Javascript components. We are starting to get some higher-level documentation around the Javascript frameworks, which is great to see! == 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 process. 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 run_tests.sh to tox, which is 90% complete (run_tests.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 listing issues. 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 discussion). 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! Richard __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev