On 10/03/16 08:46, Richard Jones wrote: > On 10 March 2016 at 18:23, Matthias Runge <[email protected] > <mailto:[email protected]>> 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 <[email protected]> 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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
