<div dir="ltr">We've solved *most* of the issues around releasing new xstatic packages, documented here[1] (and related documentation).<div><br></div><div>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:<div><div><img src="cid:ii_ilix1nfi0_153547b4957000a0" width="468" height="203"><br>​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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>SOLUTION 1: always maintain Horizon compatibility across xstatic library releases.</div><div><br></div><div>This is potentially very difficult to guarantee. So, a second solution has been proposed:</div><div><br></div><div>SOLUTION 2: move the upper-constraints information for *the xstatic libraries only* from the global upper-constraints file into Horizon's repository.</div><div><br></div><div>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</div><div><br></div><div>A variation on this solution is:</div><div><br></div><div>SOLUTION 3: allow Horizon to locally override upper-constraints for the time needed to merge a patch in devstack.</div><div><br></div><div>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.</div><div><br></div><div>SOLUTION 4: vendor the javascript</div><div><br></div><div>Heh.</div><div><br></div><div>SOLUTION 5: have dependencies on xstatic move from global requirements to Horizon</div><div><br></div><div>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.</div><div><br></div><div>Your thoughts on any and all of the above are requested.</div><div><br></div><div><br></div><div>    Richard </div><div><br></div><div><div>[1] <a href="https://review.openstack.org/#/c/289142/" target="_blank">https://review.openstack.org/#/c/289142/</a></div></div><div><br></div></div></div></div>