This session will include the following subject(s):

How far do we push devtest.sh?:

Premise:
	* devtest.sh has grown in length and complexity from the original devtest.md. 
	* We have three use cases that need to build TripleO clouds:
		* Devs
		* Testing
		* Production deployers

Questions:
	* Should devtest-of-the-future ever leave incubator?
		* If so, do we want to turn devtest into an official tripleo installer?
		* And/or if so, do we want to turn devtest into an official tripleo tester?
			* (likely merging in a ton of toci goodness)
	* And/or, should we put effort into continuing to decompose devtest into useful components that other installers can consume, with a simple devtest.sh that just runs the components?

Outcomes:
    TL;DR: 
		* devtest should just be tiny and driving tuskar for developers. 
		* Write a manual for actual deployers and give them a tuskar image to download.

(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? 
		* 3 jobs: seed isolated, undercloud isolated, overcloud isolated
		* periodic job which runs TOCI today?
		* periodic job which runs tempest against tripleocloud
		* longer term: upgrade job
	* When can we expect to be gating merges on CI tests? 
		* check testing in place by the New Year?
		* Icehouse release will be fully gated on TripleO deploys.
	* What platforms should we target ? 
		* Fedora, Ubuntu, Suse, CentOS, Debian ? (LFS)
	* How can we stabilize the reliability.
		* someone allocates time to do it.

o Virtualised resources 
	hp cloud, rackspace cloud
o what have we got 
o how can be best use them. 

o Baremetal resources, same questions 
o what have we got 
	 hp,  RH, bluebox - tripleo admined.
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 affected by breakages in unrelated projects. 

Redhat getting a cluster for TripleOCloud in the same way as the HP one
BlueBox also volunteered a region for TripleO CI - contact Hernan

(Session proposed by Robert Collins)