[openstack-dev] [Horizon] How do we move forward with xstatic releases?

Thomas Goirand zigo at debian.org
Sun Mar 13 23:15:46 UTC 2016


On 03/08/2016 05:52 AM, Richard Jones wrote:
> 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:
> 
> 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
> 
> 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.
> 
> SOLUTION 4: vendor the javascript
> 
> Heh.
> 
> 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.

SOLUTION 6: educate upstream and make them stop breaking the world.

SOLUTION 7: Stop having dependencies on libraries that constantly break
the world.

SOLUTION 8: Stop using JavaScript.

SOLUTION 9: Rewrite Horizon as QT client! :)

Cheers,

Thomas Goirand (zigo)

P.S: While all of this is just for fun, I seriously believe that
upstream JavaScript people should be educated to not break things every
2 weeks... though I don't think it will happen anytime soon.




More information about the OpenStack-dev mailing list