On 10 March 2016 at 21:48, Beth Elwell <e.r.elw...@gmail.com> wrote: > > On 10 Mar 2016, at 07:46, Richard Jones <r1chardj0...@gmail.com> wrote: > >> It has been mentioned, xstatic packages can block the gate. We currently >> control xstatic package releases, thus we can roll back, if something >> goes wrong. >> >> If we're pulling directly with npm/bower, someone from the outside can >> break us. We already have the situation with pypi packages. >> With proper packages, we could even use the gate to release those >> packages and thus verify, we're not breaking anyone. >> > > We're going to have potential breakage (gate breakage, in the integrated > tests) any time we release a package (regardless of release mechanism) and > have to update two separate repositories resulting in out-of-sync version > specification and expectation (ie. upper-constraints specification and > Horizon's code expectation) as described in my OP. The only solution that > we're aware of is to synchronise updating those two things, through one of > the mechanisms proposed so far (or possibly through a mechanism not yet > proposed.) > > If we will anyway have potential breakage I don’t understand why the > better solution here would not be to just use the bower and npm tools which > are standardised for JavaScript and would move Horizon more towards using > widely recognised tooling from within not just Openstack but the wider > development community. Back versions always need to be supported for a > time, however I would add that long term this could end up saving time and > create a stable longer term solution. >
I (and others) have argued several times for this, for a number of reasons, and it remains my preferred solution, but it has been shot down many times :-( There are three major hurdles that I recall (sorry if I forgot any, it's getting late here): 1. system packaging; installers using Debian or Red Hat (completely offline) installation will not be able to install Horizon. We don't have a solution for this though various caching mechanisms have been proposed. 2. security; the bower installation mechanism is seen as being very insecure - not that I would call the current xstatic mechanism secure. It's all down to degrees, I suppose. 3. installation in the gate; I believe that currently installation from bower would not be possible in the gate. This is pretty closely related to #1. I think I recall licensing came up at one point too, but I might be mis-remembering. Richard
__________________________________________________________________________ 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