Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

Thanks, Christopher (and the app-catalog team). On 21 March 2016 at 08:35, Christopher Aedo wrote: > On Sun, Mar 20, 2016 at 1:26 PM, Richard Jones > wrote: > > Unfortunately none of this discussion solves the substantive issue which > is > > that we

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On Sun, Mar 20, 2016 at 1:26 PM, Richard Jones wrote: > Unfortunately none of this discussion solves the substantive issue which is > that we cannot release an xstatic package without breaking the gate. > > We currently have one solution that's a close to viable as we've

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

Unfortunately none of this discussion solves the substantive issue which is that we cannot release an xstatic package without breaking the gate. We currently have one solution that's a close to viable as we've been able to get: move the version pinning for xstatic packages out of

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 13 March 2016 at 07:06, Matthias Runge wrote: > On 10/03/16 08:46, Richard Jones wrote: > > On 10 March 2016 at 18:23, Matthias Runge > > wrote: > > > > 4.alt.2: > > move to proper packages for static file management. I

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 03/17/2016 07:12 AM, Richard Jones wrote: > On 13 March 2016 at 07:11, Matthias Runge > wrote: > > On 10/03/16 11:48, Beth Elwell wrote: > > If we will anyway have potential breakage I don’t understand why the > > better solution here

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 14 March 2016 at 11:08, Thomas Goirand wrote: > > 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. > There's

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 17/03/16 08:59, Thomas Goirand wrote: >> >> Horizon, for example, currently does *not* use the upper-constraints >> pinning in its test suite or installation, so we're vulnerable to, say, >> a python-*client release that's not compatible. I have a patch in the >> works to address this, but it

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 03/17/2016 07:23 AM, Richard Jones wrote: > There's a basic difference here though. Your traditional "installed > components" are pieces of software and data used *by programs on that > system.* > > The components we're talking about here are, as far as the system is > concerned, opaque data

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 13 March 2016 at 07:11, Matthias Runge wrote: > On 10/03/16 11:48, Beth Elwell wrote: > > 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

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 03/12/2016 09:11 PM, Matthias Runge wrote: > - how often have we been blocked by releases of software not managed by > OpenStack? Seriously, that happens quite a few times over a release > cycle, not to mention breakages by releases of our own tools turning out > to block one or the other

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 03/10/2016 12:14 PM, Richard Jones wrote: > On 10 March 2016 at 21:48, Beth Elwell > wrote: > >> On 10 Mar 2016, at 07:46, Richard Jones > > wrote: >> >> It has been

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 03/10/2016 11:48 AM, Beth Elwell wrote: > >> On 10 Mar 2016, at 07:46, Richard Jones > > wrote: >> >> >> It has been mentioned, xstatic packages can block the gate. We >> currently >> control xstatic package releases, thus

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 03/09/2016 04:53 PM, Monty Taylor wrote: > On 03/07/2016 10:52 PM, Richard Jones wrote: >> We've solved *most* of the issues around releasing new xstatic packages, >> documented here[1] (and related documentation). >> >> We have one final issue that's blocking us, which is that during the >>

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 03/08/2016 05:52 AM, Richard Jones wrote: > In the Python world, we code around this by making Horizon compatible > with both the X and X1 versions of xstatic-angular (if it was a Python > library). In Javascript land this is much more difficult - Javascript > libraries tend to break

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 10/03/16 11:48, Beth Elwell wrote: > > 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

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 10/03/16 08:46, Richard Jones wrote: > On 10 March 2016 at 18:23, Matthias Runge > 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

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 10 March 2016 at 21:48, Beth Elwell wrote: > > On 10 Mar 2016, at 07:46, Richard Jones wrote: > >> It has been mentioned, xstatic packages can block the gate. We currently >> control xstatic package releases, thus we can roll back, if something >>

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 03/10/2016 11:48 AM, Beth Elwell wrote: On 10 Mar 2016, at 07:46, Richard Jones > wrote: It has been mentioned, xstatic packages can block the gate. We currently control xstatic package releases, thus we can roll back, if

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

> On 10 Mar 2016, at 07:46, Richard Jones 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

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 10 March 2016 at 18:23, Matthias Runge 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

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 09/03/16 19:52, Michael Krotscheck wrote: > On Wed, Mar 9, 2016 at 7:58 AM Monty Taylor > wrote: > > > > SOLUTION 4: vendor the javascript > > > > Heh. > > Heh indeed. > > SOLUTION 4.alt: use npm/bower instead of

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

> On 03/09/2016 04:43 PM, Serg Melikyan wrote: >>> >>> This is exactly my first thought. The plugins *must* depend on Horizon, >>> and they have to use the same versions of XStatic packages anyways, > > >> so why specify the dependencies twice? >> >> >> Plugins may require different xstatic

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

Hi Serg, There's a crucial difference: getting the solution to this wrong for Horizon will break the gate for all OpenStack projects. Updating an xstatic package that a plugin uses has no side-effect outside of the plugin. Richard On 10 March 2016 at 02:43, Serg Melikyan

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On Wed, Mar 9, 2016 at 7:58 AM Monty Taylor wrote: > > > SOLUTION 4: vendor the javascript > > > > Heh. > > Heh indeed. > > SOLUTION 4.alt: use npm/bower instead of xstatic to pull the javascript. > +1. Let's move the codebase forward, instead of continuing to build hacky

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 10 Mar 2016 2:58 AM, "Radomir Dopieralski" wrote: > > On 03/09/2016 04:43 PM, Serg Melikyan wrote: >>> >>> This is exactly my first thought. The plugins *must* depend on Horizon, >>> and they have to use the same versions of XStatic packages anyways, > > >> so why

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 03/09/2016 04:43 PM, Serg Melikyan wrote: This is exactly my first thought. The plugins *must* depend on Horizon, and they have to use the same versions of XStatic packages anyways, >> so why specify the dependencies twice? Plugins may require different xstatic library, which is not even

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 03/07/2016 10:52 PM, Richard Jones wrote: We've solved *most* of the issues around releasing new xstatic packages, documented here[1] (and related documentation). We have one final issue that's blocking us, which is that during the xstatic release there will be a point at which Horizon may

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

>This is exactly my first thought. The plugins *must* depend on Horizon, and >they have to use the same versions of XStatic packages anyways, so why specify >the dependencies twice? Plugins may require different xstatic library, which is not even used by Horizon. Issue raised by Richard exists

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 03/08/2016 11:43 PM, David Lyle wrote: I'm wondering if since horizon is really the only project consuming these xstatic libraries and none are likely to venture down this path of madness with us that it would be safe to manage the xstatic requirements and upper-constraints locally.

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 9 March 2016 at 14:23, Jeremy Stanley wrote: > On 2016-03-09 13:57:45 +1300 (+1300), Robert Collins wrote: >> On 9 March 2016 at 13:07, Jeremy Stanley wrote: >> > On 2016-03-08 17:25:41 +1100 (+1100), Richard Jones wrote: >> > [...] >> >> SOLUTION 6 -

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 2016-03-09 13:57:45 +1300 (+1300), Robert Collins wrote: > On 9 March 2016 at 13:07, Jeremy Stanley wrote: > > On 2016-03-08 17:25:41 +1100 (+1100), Richard Jones wrote: > > [...] > >> SOLUTION 6 - make zuul capable of performing atomic cross-repository > >> commits. > > > >

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 9 March 2016 at 13:07, Jeremy Stanley wrote: > On 2016-03-08 17:25:41 +1100 (+1100), Richard Jones wrote: > [...] >> SOLUTION 6 - make zuul capable of performing atomic cross-repository >> commits. > > This seems unlikely to happen, as it's very much counter to Zuul's >

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

But Jeremy: Atomic Zuul. How cool is that name. So I know I'm going to potentially get yelled at for voicing this, but what are the chances that app-catalog and Horizon are ever installed on the same system? That is, could it have its own xstatic constraints, with the promise that the two

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 2016-03-08 17:25:41 +1100 (+1100), Richard Jones wrote: [...] > SOLUTION 6 - make zuul capable of performing atomic cross-repository > commits. This seems unlikely to happen, as it's very much counter to Zuul's designed-in reliance on serializing changes to test before merging them. -- Jeremy

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On Mon, Mar 7, 2016 at 9:52 PM, Richard Jones wrote: > We've solved *most* of the issues around releasing new xstatic packages, > documented here[1] (and related documentation). > > We have one final issue that's blocking us, which is that during the > xstatic release

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

Two things I forgot to mention: Currently there is another break point in the diagram of releases when X1 is released. Currently Horizon does not use upper-constraints and thus will immediately pick up the new xstatic release file, potentially breaking things. This is easy to fix - I will be

[openstack-dev] [Horizon] How do we move forward with xstatic releases?

We've solved *most* of the issues around releasing new xstatic packages, documented here[1] (and related documentation). We have one final issue that's blocking us, which is that during the xstatic release there will be a point at which Horizon may be broken from an integrated point of view -