Trove Integration tests running as part of Tempest.


In order to achieve this, a number of smaller work items need to happen:


	1. Trove dib elements need to be moved out into a separate repo, so that a dib run can build the guestagent
	
		- Initial thought was to move trove dib (diskimage-builder) elements into their own repo
			- https://review.openstack.org/#/c/53972/
			
		- After discussion with lifeless, it's probably worth considering moving the elements into the tripleo-image-elements repository
			- Pros: (We are going with this one!!!)
				- One place for the elements needed to build the guestagent
				- Leverage common tests across multiple elements
				- Getting tripleo core-reviewer eyeballs on the project 
			- Cons:
				- Tighter couping (?) between tripleo and trove elements
				- Is there a way to kick off a build based on a change in part of the repo? Or is there an alternative?
	
		-Some sort of scheduled build of the image as well? yes, say... daily
	
	2. Make job on devstack gate on this repo to build dib guestagent Ubuntu and Fedora images on repo changes.
		a. This job might need to run on changes to dib as well, to ensure that those changes haven't broken our image builds.


	3. Once built, the job publishes the images to a location (tarballs.o.o?) for caching.
		a. Will the image size be an issue? (~450M today for the qcow2 image)
		(No resource constraint, this is non-issue)
		
	4. What trove-int does today to prepare running the integration tests:
		a. Install test packages (openstack.nose_plugin proboscis pexpect) => Not needed for tempest?
		b. Update test.conf to pass in conf values specifically for the tests => Needed or equivalent in devstack-gate / tempest?
		c. Add test-related users (admin vs. non admin users for tests) => Needed or equivalent in devstack-gate / tempest? (this becomes test resources for users in Tempest?)
		d. Add test-related flavors (different sizes for flavor-related tests / ephemeral flavors) => Needed or equivalent in devstack-gate / tempest? (test resources)
		e. Setup IPtables masquerade rule for network connectivity. (this seems like a VM hack)
		(use pypi mirror from Infra)
		f. clearly define what activities should be carried out in devstack gate (i.e. appropriate use of)
		join tempest irc meeting to chat about tempest specifics


	5. Update tempest to write integration tests for Trove that can run on devstack-gate. These tests can use the cached image from above.
		a. Do we start porting tests, or have a wrapper / adapter to purpose the existing integration tests? (Some basic framework to build trove tests on.)
		b. We still need to figure out a clean way to handle integration tests on the guest instance. 
			- Currently proboscis supports dependencies on previous tests, but tempest does not.
				- Is it best not to have dependencies between tests? (It is!) (is too- but we didn't have time to discuss this so I guess I should drop it)
		c. How can we run certain sets of tests in parallel to achieve efficiency?
		
		Able to make old tests a voting job, but just for Trove check ins.
		

	6. Also revisit trove-int and update it to use cached images?
		- What pieces of trove-int do we want to sunset after we've moved our integration tests to tempest?
		- What happens to fake mode for trove-integration? 
		
	7. WTF is fake mode?
		- Nova already has a fake virt driver; see joe gordon (jog0)
		- We would need a guest "fake"
		
(Feel free to add more items that you think relevant.
I will add more details to some of these points, and clarify some of these questions as we make more progress on this work-item)