Open Stack

On 03/10/2016 12:14 PM, Richard Jones wrote:
> On 10 March 2016 at 21:48, Beth Elwell <e.r.elwell at gmail.com
> <mailto:e.r.elwell at gmail.com>> wrote:
> 
>>     On 10 Mar 2016, at 07:46, Richard Jones <r1chardj0n3s at gmail.com
>>     <mailto:r1chardj0n3s at 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 :-(

And I will attempt to do it once more unless someone brings the right
argumentation to the table.

> 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

>From a distribution package maintainer perspective, the most annoying
part is that there's no easy way to get the web app use the JS libs from
the OS, and there's no system wide registry of installed components.
XStatic does that. Get $your-favoring-js-package-manager to do it, just
like php pear, perl CPAN, or Python pip does, then we will adopt it.
This, of course, requires work on upstream tooling.

Cheers,

Thomas Goirand (zigo)