Open Stack

On 10/03/16 08:46, Richard Jones wrote:
> On 10 March 2016 at 18:23, Matthias Runge <mrunge at redhat.com
> <mailto:mrunge at redhat.com>> wrote:
> 
>     4.alt.2:
>     move to proper packages for static file management. I mean, they need to
>     be built anyways.
> 
> 
> Please define what you mean by "proper packages" here. I *think* you
> might mean system packages (aka Debian or Red Hat) which is not feasible
> given other environments that Horizon runs under. Please correct me if
> I'm wrong!

Exactly. I mean system packages. If there are issues with system
packages, then let's address the issue rather than re-inventing the wheel.

Weren't we just talking about providing dependencies for the gate? I
mean, for production, it's quite the same situation we are at the
moment. Nobody requires you to install Horizon and dependencies
especially via rpm, deb or pip: Take what you want.

>     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.)
> 

Yes, and my proposal to address this is to gate updating/releasing
dependencies the same way we're currently gating each change in horizon.

> 
> 1. Horizon maintains its own constrained version list for the xstatic
> packages,
> 2. Plugins to Horizon must depend on Horizon to supply xstatic packages
> except where they use additional packages that Horizon does not use, and
> 3. We avoid installing app-catalog (the system, not the plugin) in the
> integrated tests (I don't believe doing this is even on the ...
> "horizon" so to speak) *or* in a Debian / Red Hat (i.e. system-packaged)
> system that also has Horizon installed. Or we try to convince
> app-catalog to stay lock-step with Horizon's xstatic versions. I
> understand the risk of a collision between app-catalog and Horizon in
> the same system-packaged environment is very low.

I don't really see a chance for app-catalog to require Horizon as a
dependency and different versions of xstatic packages. This would be an
immediate show-stopper for app-catalog either on Debian or on RPM based
systems.

Let me repeat myself: you're free to install dependencies as you like,
npm, bower, whatever. I was simply speaking about the gate and about
gating dependencies to be sure, we're not broken by someone from outside.

Matthias
-- 
Matthias Runge <mrunge at redhat.com>

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
                    Michael O'Neill