*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