Open Stack

On 03/07/2016 10:52 PM, Richard Jones 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:
>
> ​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.

Yah. Honestly, this is one of the main places where I think we get into 
trouble in linux-distro land in trying to apply the tools/techniques 
developed for one set of problems with another.

> 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:
>
> 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 actually like this one a lot. I know that there is a plugin problem 
... but ... plugin installers could also consume the horizon xstatic 
constraints when installing xstatic packages?

xstatic packages are specifically workarounds for doing javascript in a 
python-centric world. Putting then in upper-constraints and actually 
treating them like actual python packages rather than what they are 
which is a clever utilization of the python ecosystem to deliver 
javascript libraries is vexing at best.


> 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.

Or people who are deploying horizon CD from master from source and 
applying upper-constraints to get the tested version. Those people would 
have to duplicate the tox logic.

> SOLUTION 4: vendor the javascript
>
> Heh.

Heh indeed.

SOLUTION 4.alt: use npm/bower instead of xstatic to pull the javascript.

>
> 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.
>
> Your thoughts on any and all of the above are requested.

Thanks for your work on this - it's a hard problem - especially with 
sets of potentially conflicting desires from your consumers.