[horizon] Shanghai PTG recap

Akihiro Motoki amotoki at gmail.com
Fri Dec 6 11:18:15 UTC 2019


I am summarizing the horizon PTG in Shanghai.
One month passed from the PTG, but I believe the summary is still useful :-)

Eight folks joined the session and we had productive discussions.
Thanks all!

- PTG etherpad https://etherpad.openstack.org/p/horizon-u-ptg
- release priority etherpad

[Priorities for Ussuri]
After the PTG, we discussed the project priorities for Ussuri based on
the PTG discussion and agreed the following as project priorities.
We will cover them in the weekly team meetings.

  * High
    * Catch up the new policy mechanism
    * Bump and clean up Django versions
    * Error message refactoring
  * Medium
    * xstatic updates
    * ini-based-configuration
    * Chinese translation handling

[PTG recap]

* Train retrospective
  * To keep
    * We succeeded to restore integration tests in horizon and several
plugins. They just cover basic GET scenarios. Most JS tests do not
cover scenario testing so it would be a good step to avoid plugin
    * We can keep the project healthiness to some level regardless of
the low number of contributors.
  * To improve
    * The bundle policy files in horizon is out of date from back-end
services and there was no progress since Stein release. For example,
the new policies (system scope, deprecated policies) from the keystone
repo does not work with horizon. It should be priorities in Ussuri
release. We will join the pop-up team for the policy enhancement.
    * Some community goal from queens has not completed. (Most of them
have done.)

* Supported versions of Django and Python
  * We discussed the plan to enable Django 2.2 (the current LTS) by
default and drop Django 1.11 support. The current plan is to bump the
default Django to 2.2 around milestone-1 and drop Django 1.11 support
by milestone-2. The minimum goal is to support Django 2.2 as it will
be the only LTS supported by Django community as of Ussuri release.
  * The version changes in Django may break horizon plugins so we need
enough time to test them in real deployments.
  * Integration test coverage would help the transition of Django
version and let's try integration tests more with our best.

* X-Static updates
  * Many xstatic packages are not updated for long. They has has fixes
including security fixes, so we need to update them. radomir
volunteered for the effort.

* JS loading
  * e0ne shared his experiences on his trial to implement a plugin
using react.
  * The problem is that it is not easy to use newer JS libraries. An
example of problmes with a current approach is
  * It comes from the gap between the xstatic way to use same versions
for all JS applications and modern JS packaging like webpack.
  * There is no good conclusion in this topic, but a long-term goal
would be to use modern packaging mechanism instead of xstatic. It
could be an issue for distribution packagers.

* Horizon plugins maintenance
  * This slot covered topics around horizon plugin ecosystem and their
  * The main outcomes are:
  * we agreed to change the release model of horizon to
cycle-with-intermediary. Horizon plugins use horizon as library and we
need to release horizon promptly whenever we have changes which affect
plugins. cycle-with-intermediary model would fit more for this
    * A concern on that multiple major version bump potentially
happens was raised, but we agreed that the version number does not
matter and the best practice to avoid this is to drop deprecated
features at the beginning of the cycle.
  * horizon team asked individual project teams with horizon plugins
to give +2 right to horizon cores to make plugin maintenance smooth.
     * Most team agreed and we had conversations with more team at the PTG.
     * One important note is that horizon team should shouldn’t merge
anything to plugins without +2 from plugin team.
     * We will update our documentation to cover this change in the
plugin maintenance and e0ne volunteered for it.
   * Some side-discussion happened. There was no decision but they
might be worth considering in future.
     * An idea to split nova/cinder/neutron/keystone/.... support to
plugins and make them mandatory dependencies.
     * Use of micro-frontend concept

* Chinese translation handling
  * From horizon perspective we agreed that we would like to move to
the new locale names (zh-hans/hant) both in horizon (+plugins).
  * The main questions are the transition plan and locales for
documentations. Further discussion with the i18n team happened in
Shanghai. The summary of the discussion will be coming soon, but the
first step agreed is that the horizon team confirms the new locales
work fine in horizon.

* Feature Gaps
  * Brief discussions happened for features with volunteers.
  * We will visit the status of the gaps in the etherpad

* Refactor Error Messages
   * We received a good number of bug reports which complain that
horizon error messages are too general and hide error details.
  * We agree to show both error message summary (translated) and
detail message from API.
  * An idea discussed is to have a collapsible box to show an error
detail along with a summary message. This approach would bring us a
good balance of translated message and error detail from back-end
  * It would be a nice improvement in Ussuri.

* Deprecations and Removals
  * Short discussion covered potential feature deprecation and removals.
  * Cinder v2 support will be dropped soon.

* ini-based-configuration
  * amotoki expressed that he continues the effort and hopefully
completes it in Ussuri.

* API versions of backend services
  * horizon uses the minimum microversions to communicate with
back-end services unless new versions are required to support
  * The possibility to bump the minimum versions used (per cycle?) was
discussed and we agreed to keep the current strategy considering dev
resources and maintenance.
  * Adoption of openstacksdk was discussed. openstacksdk supports
older APIs and it would help us keep the current strategy on API
versions used.
  * To use openstacksdk, we need to explore how to instantiate
keystonauth Auth object with a token (as horizon stores only token and
does not store auth information). We can start the investigation on
this and e0ne volunteered.

That's all we discussed in Shanghai.
I hope we will have good progress in Ussuri.

Best Regards,
Akihiro Motoki (irc: amotoki)

More information about the openstack-discuss mailing list