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