*Zuul job runners and log management
*Session proposed by James E. Blair
*Wednesday November  6, 2013  4:40pm -  5:20pm
*Design Summit 1
*Infrastructure

This session will include the following subject(s):

*Log management:

We  should decide on a plan for how to deal with log storage, processing,  serving, etc for all the logs that are produced from our test runs.

See this mailing list thread on the subject:

http://lists.openstack.org/pipermail/openstack-infra/2013-October/000327.html

	* push logs to swift using tempurl middleware
		* possibly give 3rd party testers swift container access
		* generate html index pages within the job for run-level files
		* no more change or patchset level indexes
			* possibly append url for each run to a log to make that data recoverable for future big-data processing needs
	* os-loganalyze will serve logs (as does now) from disk or swift
try to use swift index generation
shove old logs in
reporter to log full patchset results?

*Job runners for Zuul:

Let's design a non-Jenkins job runner for Zuul. Rough starting requirements:
	* Distributed (no centralized 'master' architecture)
	* Secure (should be able to run untrusted jobs)
	* Should be able to publish artifacts appropriate to a job's security context
	* Lightweight (should do one job and simply)

	* change gearman protocol?
	* use salt?
		* breaks compatibility with jenkins