Re: [openstack-dev] [requirements] [infra] speeding up gate runs?

2015-11-04 Thread Ian Wienand
On 11/05/2015 01:43 AM, Matthew Thode wrote: python wheel repo could help maybe? So I think we've (i.e. greghaynes) got that mostly in place, we just got a bit side-tracked. [1] adds mirror slaves, that build the wheels using pypi-mirror [2], and then [3] adds the jobs. This should give us wh

Re: [openstack-dev] [requirements] [infra] speeding up gate runs?

2015-11-04 Thread Gregory Haynes
Excerpts from Jeremy Stanley's message of 2015-11-04 21:31:58 +: > On 2015-11-04 15:34:26 -0500 (-0500), Sean Dague wrote: > > This seems like incorrect logic. We should test devstack can do all the > > things on a devstack change, not on every neutron / trove / nova change. > > I'm fine if we

Re: [openstack-dev] [requirements] [infra] speeding up gate runs?

2015-11-04 Thread Jeremy Stanley
On 2015-11-04 15:34:26 -0500 (-0500), Sean Dague wrote: > This seems like incorrect logic. We should test devstack can do all the > things on a devstack change, not on every neutron / trove / nova change. > I'm fine if we want to have a slow version of this for devstack testing > which starts from

Re: [openstack-dev] [requirements] [infra] speeding up gate runs?

2015-11-04 Thread Sean Dague
On 11/04/2015 03:27 PM, Clark Boylan wrote: > On Wed, Nov 4, 2015, at 09:14 AM, Sean Dague wrote: >> On 11/04/2015 12:10 PM, Jeremy Stanley wrote: >>> On 2015-11-04 08:43:27 -0600 (-0600), Matthew Thode wrote: On 11/04/2015 06:47 AM, Sean Dague wrote: >>> [...] > Is there a nodepool cache

Re: [openstack-dev] [requirements] [infra] speeding up gate runs?

2015-11-04 Thread Clark Boylan
On Wed, Nov 4, 2015, at 09:14 AM, Sean Dague wrote: > On 11/04/2015 12:10 PM, Jeremy Stanley wrote: > > On 2015-11-04 08:43:27 -0600 (-0600), Matthew Thode wrote: > >> On 11/04/2015 06:47 AM, Sean Dague wrote: > > [...] > >>> Is there a nodepool cache strategy where we could pre build these? A 25%

Re: [openstack-dev] [requirements] [infra] speeding up gate runs?

2015-11-04 Thread Robert Collins
On 5 November 2015 at 07:37, Sean Dague wrote: > It only really will screw when upper-constraints.txt gets updated on a > branch. Bah, yes. > I honestly think it's ok to not be perfect here. In the base case we'll > speed up a good chunk, and we'll be slower (though not as slow as today) > for

Re: [openstack-dev] [requirements] [infra] speeding up gate runs?

2015-11-04 Thread Sean Dague
On 11/04/2015 01:26 PM, Robert Collins wrote: > On 5 November 2015 at 06:21, Morgan Fainberg > wrote: >> > ... >> >> If it is that easy, what a fantastic win in speeding things up! > > It'll help, but skew as new things are released - so e.g. after a > release of numpy until the next image build

Re: [openstack-dev] [requirements] [infra] speeding up gate runs?

2015-11-04 Thread Robert Collins
On 5 November 2015 at 06:21, Morgan Fainberg wrote: > ... > > If it is that easy, what a fantastic win in speeding things up! It'll help, but skew as new things are released - so e.g. after a release of numpy until the next image builds and is enabled successfully. We could have a network mirror

Re: [openstack-dev] [requirements] [infra] speeding up gate runs?

2015-11-04 Thread Morgan Fainberg
On Nov 4, 2015 09:14, "Sean Dague" wrote: > > On 11/04/2015 12:10 PM, Jeremy Stanley wrote: > > On 2015-11-04 08:43:27 -0600 (-0600), Matthew Thode wrote: > >> On 11/04/2015 06:47 AM, Sean Dague wrote: > > [...] > >>> Is there a nodepool cache strategy where we could pre build these? A 25% > >>> p

Re: [openstack-dev] [requirements] [infra] speeding up gate runs?

2015-11-04 Thread Sean Dague
On 11/04/2015 12:10 PM, Jeremy Stanley wrote: > On 2015-11-04 08:43:27 -0600 (-0600), Matthew Thode wrote: >> On 11/04/2015 06:47 AM, Sean Dague wrote: > [...] >>> Is there a nodepool cache strategy where we could pre build these? A 25% >>> performance win comes out the other side if there is a str

Re: [openstack-dev] [requirements] [infra] speeding up gate runs?

2015-11-04 Thread Jeremy Stanley
On 2015-11-04 08:43:27 -0600 (-0600), Matthew Thode wrote: > On 11/04/2015 06:47 AM, Sean Dague wrote: [...] > > Is there a nodepool cache strategy where we could pre build these? A 25% > > performance win comes out the other side if there is a strategy here. > > python wheel repo could help maybe

Re: [openstack-dev] [requirements] [infra] speeding up gate runs?

2015-11-04 Thread Sean Dague
On 11/04/2015 07:47 AM, Sean Dague wrote: > I was spot checking the grenade multinode job to make sure it looks like > it was doing the correct thing. In doing so I found that ~15minutes of > it's hour long build time is compiling lxml and numpy 3 times each. > > Due to our exact calculations by u

Re: [openstack-dev] [requirements] [infra] speeding up gate runs?

2015-11-04 Thread Sean Dague
On 11/04/2015 10:50 AM, Brant Knudson wrote: > > > On Wed, Nov 4, 2015 at 6:47 AM, Sean Dague > wrote: > > I was spot checking the grenade multinode job to make sure it looks like > it was doing the correct thing. In doing so I found that ~15minutes of > it's

Re: [openstack-dev] [requirements] [infra] speeding up gate runs?

2015-11-04 Thread Brant Knudson
On Wed, Nov 4, 2015 at 6:47 AM, Sean Dague wrote: > I was spot checking the grenade multinode job to make sure it looks like > it was doing the correct thing. In doing so I found that ~15minutes of > it's hour long build time is compiling lxml and numpy 3 times each. > > I've always wondered why

Re: [openstack-dev] [requirements] [infra] speeding up gate runs?

2015-11-04 Thread Matthew Thode
On 11/04/2015 06:47 AM, Sean Dague wrote: > I was spot checking the grenade multinode job to make sure it looks like > it was doing the correct thing. In doing so I found that ~15minutes of > it's hour long build time is compiling lxml and numpy 3 times each. > > Due to our exact calculations by u

[openstack-dev] [requirements] [infra] speeding up gate runs?

2015-11-04 Thread Sean Dague
I was spot checking the grenade multinode job to make sure it looks like it was doing the correct thing. In doing so I found that ~15minutes of it's hour long build time is compiling lxml and numpy 3 times each. Due to our exact calculations by upper-constraints.txt we ensure exactly the right ver