Open Stack

On 13 March 2016 at 07:06, Matthias Runge <mrunge at redhat.com> wrote:

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

OK, the sticking point is that installation through system packages alone
forces us to make all software on a system work with a single version of
any given library. This has spawned the global-requirements and now
upper-constraints systems in OpenStack, and ultimately leads to the
problematic race condition that resulted in me starting this email thread.
That is, we can update *either* the version of a library being used *or*
the software that is compatible with that version *but not the two at the
same time, atomically*.



> Weren't we just talking about providing dependencies for the gate?


Well, partially, because the reason the problem surfaces is because of the
Continuous Deployment guarantee that OpenStack makes, which is enforced by
the gate, so sure, let's say it's the gate's fault <wink>



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

I'm not sure it's this simple, is it? Folks want to be able to install
OpenStack from a single source, and that seems reasonable. They want to be
able to do that "offline" too, so that rules out bower as a source of
packages.



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

This is not going to solve the race condition I mention; it's actually
during our work implementing gating these releases that we found we had to
solve this problem.



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

I think I used the wrong word above. Where I said "system" I probably
should have said "server". app-catalog the stand-alone server should not
depend on Horizon, just app-catalog the plugin to Horizon should (like all
Horizon plugins should).



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


Again, I don't believe we have the freedom to actually install dependencies
as we like, as I said above.


      Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160317/f7bfa6be/attachment.html>