On 08/19/2014 12:41 PM, Derek Higgins wrote:
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. Before we go about making these changes I'd like to go
through a few questions for firm things up
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?
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?
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
GPG KEY: 08D733BA
OpenStack-dev mailing list