Open Stack

On 19/08/14 13:07, Giulio Fidente wrote:
> On 08/19/2014 12:41 PM, Derek Higgins wrote:
>> Hi All,
>>
>>     I'd like to firm up our plans around the ci jobs we discussed at the
>> tripleo sprint, at the time we jotted down the various jobs on an
>> etherpad, to better visualize the matrix of coverage I've put it into a
>> spreadsheet[1]. Before we go about making these changes I'd like to go
>> through a few questions for firm things up
> 
> hi Derek!
> 
>> 1. Did we miss any jobs that we should have included?
>>     gfidente mentioned on IRC about adding blockstoragescale and
>> swiftstoragescale jobs into the mix, should we add this to the matrix so
>> at each is tested on at least one of the existing jobs?
> 
> thanks for bringing this up indeed
> 
> mi idea is the following: given we have support for blockstorage nodes
> scaling in devtest now and will (hopefully soon) have the option to
> scale swift nodes too, it'd be nice to test an OC where we have volumes
> and objects stored on those separate nodes
> 
> this would test our ability to deploy such a configuration and we have
> tests for this set in place already as our user image is now booting
> from volume and glance is backed by swift
> 
> so maybe a nonha job with 1 external blockstorage and 2 external swift
> nodes would be a nice to have?

I've added block scaling and swift scaling to the matrix and have
included each in one of the tests, this should give us coverage on both,
so I think we can do this without adding a new job.

> 
>> 3. Are there any jobs here we should remove?
> 
> I was suspicious about the -juno and -icehouse jobs.
> 
> Are these jobs supposed to be test lates 'stable' (juno) and 'stable -1'
> (icehouse) releases, with all other jobs deploying from 'K trunk?

I'm having difficulty recalling what we decided at the sprint, but long
term latest stable sounds like a must, anybody know where the notes are
on this?

> 
>> Once anybody with an opinion has had had a chance to look over the
>> spreadsheet, I'll start to make changes to our existing jobs so that
>> they match jobs on the spreadsheet and then add the new jobs (one at a
>> time)
>>
>> Feel free to add comments to the spreadsheet or reply here.
> 
> One last comment, maybe a bit OT but I'm raising it here to see what is
> the other people opinion: how about we modify the -ha job so that at
> some point we actually kill one of the controllers and spawn a second
> user image?