Please note: This schedule is for OpenStack Active Technical Contributors participating in the Icehouse Design Summit sessions in Hong Kong. These are working sessions to determine the roadmap of the Icehouse release and make decisions across the project. To see the full OpenStack Summit schedule, including presentations, panels and workshops, go to http://openstacksummitnovember2013.sched.org.
This session will include the following subject(s):
How far do we push devtest.sh?:
devtest.sh has grown in length and complexity from the original devtest.md.
Do we want to keep evolving it until it becomes a defacto standard for bootstrapping a cloud? Where do we draw the lines here?
FWIW I would like to see us continue to decompose devtest.sh into components that will be individually useful to wider audiences, while making it easy for devs to spin up a full environment.
I'd like to get some wider opinions though, since we have multiple semi-intersecting interests here (devs, testing, deployers). If nothing else, the name might want to be revisited if/when toci merges into incubator :)
(Session proposed by Chris Jones)
CI testing:
We need toci in core - so we have scaled tests and get checks when nova changes occur etc. Other things to consider talking about
What jobs should we be running? When can we expect to be gating merges on CI tests? What platforms should we target ? How can we stabilize the reliability.
o Virtualised resources o what have we got o how can be best use them.
o Baremetal resources, same questions o what have we got o how can be best use them. o Is there more resources available, where, when ?
We also need to setup a periodic job that updates a set of known working project git hashes which can be feed into any gerrit triggered jobs. So the gerrit commits wont be effected by breakages in unrelated projects.
