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