Open Stack

On 03/09/2016 04:53 PM, Monty Taylor wrote:
> 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.

Veto. See "Why we use XStatic" at:
https://github.com/openstack/horizon/blob/master/doc/source/topics/packaging.rst

Thomas