<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 13 March 2016 at 07:06, Matthias Runge <span dir="ltr"><<a href="mailto:mrunge@redhat.com" target="_blank">mrunge@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/03/16 08:46, Richard Jones wrote:<br>
> On 10 March 2016 at 18:23, Matthias Runge <<a href="mailto:mrunge@redhat.com">mrunge@redhat.com</a><br>
</span><span class="">> <mailto:<a href="mailto:mrunge@redhat.com">mrunge@redhat.com</a>>> wrote:<br>
><br>
>     4.alt.2:<br>
>     move to proper packages for static file management. I mean, they need to<br>
>     be built anyways.<br>
><br>
><br>
> Please define what you mean by "proper packages" here. I *think* you<br>
> might mean system packages (aka Debian or Red Hat) which is not feasible<br>
> given other environments that Horizon runs under. Please correct me if<br>
> I'm wrong!<br>
<br>
</span>Exactly. I mean system packages. If there are issues with system<br>
packages, then let's address the issue rather than re-inventing the wheel.<br></blockquote><div><br></div><div>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*.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Weren't we just talking about providing dependencies for the gate?</blockquote><div><br></div><div>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></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I mean, for production, it's quite the same situation we are at the<br>
moment. Nobody requires you to install Horizon and dependencies<br>
especially via rpm, deb or pip: Take what you want.<br></blockquote><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>     It has been mentioned, xstatic packages can block the gate. We currently<br>
>     control xstatic package releases, thus we can roll back, if something<br>
>     goes wrong.<br>
><br>
>     If we're pulling directly with npm/bower, someone from the outside can<br>
>     break us. We already have the situation with pypi packages.<br>
>     With proper packages, we could even use the gate to release those<br>
>     packages and thus verify, we're not breaking anyone.<br>
><br>
><br>
> We're going to have potential breakage (gate breakage, in the integrated<br>
> tests) any time we release a package (regardless of release mechanism)<br>
> and have to update two separate repositories resulting in out-of-sync<br>
> version specification and expectation (ie. upper-constraints<br>
> specification and Horizon's code expectation) as described in my OP. The<br>
> only solution that we're aware of is to synchronise updating those two<br>
> things, through one of the mechanisms proposed so far (or possibly<br>
> through a mechanism not yet proposed.)<br>
><br>
<br>
</span>Yes, and my proposal to address this is to gate updating/releasing<br>
dependencies the same way we're currently gating each change in horizon.<br></blockquote><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> 1. Horizon maintains its own constrained version list for the xstatic<br>
> packages,<br>
> 2. Plugins to Horizon must depend on Horizon to supply xstatic packages<br>
> except where they use additional packages that Horizon does not use, and<br>
> 3. We avoid installing app-catalog (the system, not the plugin) in the<br>
> integrated tests (I don't believe doing this is even on the ...<br>
> "horizon" so to speak) *or* in a Debian / Red Hat (i.e. system-packaged)<br>
> system that also has Horizon installed. Or we try to convince<br>
> app-catalog to stay lock-step with Horizon's xstatic versions. I<br>
> understand the risk of a collision between app-catalog and Horizon in<br>
> the same system-packaged environment is very low.<br>
<br>
</span>I don't really see a chance for app-catalog to require Horizon as a<br>
dependency and different versions of xstatic packages. This would be an<br>
immediate show-stopper for app-catalog either on Debian or on RPM based<br>
systems.<br></blockquote><div><br></div><div>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).</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Let me repeat myself: you're free to install dependencies as you like,<br>
npm, bower, whatever. I was simply speaking about the gate and about<br>
gating dependencies to be sure, we're not broken by someone from outside.</blockquote><div><br></div><div>Again, I don't believe we have the freedom to actually install dependencies as we like, as I said above.</div><div><br></div><div><br></div><div>      Richard</div><div><br></div></div></div></div>