[openstack-dev] [Horizon][app-catalog] How do we move forward with xstatic releases?

Fox, Kevin M Kevin.Fox at pnnl.gov
Tue Mar 8 23:48:44 UTC 2016


fyi, we are planning on using the xstatic packages for the app catalog website so we can share as much code as possible with horizon and the app catalog horizon plugin. So it will affect the app catalog too, not just horizon.

Thanks,
Kevin
________________________________
From: David Lyle [dklyle0 at gmail.com]
Sent: Tuesday, March 08, 2016 2:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?



On Mon, Mar 7, 2016 at 9:52 PM, Richard Jones <r1chardj0n3s at gmail.com<mailto:r1chardj0n3s at gmail.com>> wrote:
We've solved *most* of the issues around releasing new xstatic packages, documented here[1] (and related documentation).

We have one final issue that's blocking us, which is that during the xstatic release there will be a point at which Horizon may be broken from an integrated point of view - some of the interfaces may not work and fail tests. The process goes something like this:
[cid:ii_ilix1nfi0_153547b4957000a0]
​Note: this assumes that depends-on can reliably bring in patches from all over the place into a gate environment, which is technically possible, but not necessarily correct today.

The problem is that because we can't atomically update both upper-constraints *and* Horizon at the same time (or upper-constraints *and* xstatic-angular, or Horizon *and* xstatic-angular) we run into a situation where Horizon will be running against the wrong version of xstatic-angular.

So we break one of the basic assumptions of the OpenStack world: that every single commit in every repository for the integrated environment will pass tests.

In the Python world, we code around this by making Horizon compatible with both the X and X1 versions of xstatic-angular (if it was a Python library). In Javascript land this is much more difficult - Javascript libraries tend to break compatibility in far more interesting ways. Maintaining compatibility across CSS and font releases is also a difficult problem, though changes here are unlikely to break Horizon enough that gate tests would fail. So, solution 1 to the problem is:

SOLUTION 1: always maintain Horizon compatibility across xstatic library releases.

This is potentially very difficult to guarantee. So, a second solution has been proposed:

This seems unlikely to go well.


SOLUTION 2: move the upper-constraints information for *the xstatic libraries only* from the global upper-constraints file into Horizon's repository.

This allows us to atomically update both Horizon and the xstatic library version, removing the potential to break because of the version mismatch. Unfortunately it means that we have version compatibility issues with anything else that wants to install alongside Horizon that also uses xstatic packages. For example, Horizon plugins. We could move Horizon plugins into the Horizon repository to solve this. /ducks

I don't know that you can duck low enough for that.

I'm wondering if since horizon is really the only project consuming these xstatic libraries and none are likely to venture down this path of madness with us that it would be safe to manage the xstatic requirements and upper-constraints locally.

Technically the plugins for horizon depend on this, but they depend via horizon. If they require specific versions that are not supported by Horizon, I think all bets are off anyway.


A variation on this solution is:

SOLUTION 3: allow Horizon to locally override upper-constraints for the time needed to merge a patch in devstack.

This solution allows Horizon to atomically update itself and the xstatic library, but it also means installing Horizon in a CI/CD environment becomes more difficult due to the need to always pull down the upper-constraints file and edit it. We could code this in to tox, but that doesn't help eg. devstack which needs to also do this thing.


I combined this with #2.

SOLUTION 4: vendor the javascript

Heh.

This makes me sad.


SOLUTION 5: have dependencies on xstatic move from global requirements to Horizon

This is similar to 2 & 3 with some of the same drawbacks (multiple users of xstatic) but also we'd need a change to global-requirements handling to ignore some entries in Horizon's requirements.


I guess I combined 2, 3 and 5. Just remove the xstatic overhead from the openstack global mechanism.

Your thoughts on any and all of the above are requested.


    Richard

[1] https://review.openstack.org/#/c/289142/


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160308/40640fdc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: update-break.png
Type: image/png
Size: 19712 bytes
Desc: update-break.png
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160308/40640fdc/attachment.png>


More information about the OpenStack-dev mailing list