Open Stack

Hi,

At the PTG we brainstormed a road map for Zuul once we completed the
infra cutover.  I think we're in a position now that we can get back to
thinking about this, so I've (slightly) cleaned it up and organized it
here.

I've grouped into a number of sections.  First:

Very Near Term
--------------

These are things that we should be able to land within just a few weeks
at most, once we're back from the OpenStack summit and can pay more
attention to work other than the openstack-infra migration.  All of
these are already in progress (some are basically finished) and all have
a primary driver assigned:

* granular quota support in nodepool (tobias)
* zuul-web dashboard (tristanC)
* update private key api for zuul-web (jeblair)
* github event ingestion via zuul-web (jlk)
* abstract flag (do not run this job) (jeblair)
* zuul_json fixes (dmsimard)

Short Term
----------

These are things we should be able to do within the weeks or months
following.  Some have had work start on them already and have a driver
assigned, others are still up for grabs.  These are things we really
ought to get done before the v3.0 release because either they involve
some of the defining features of v3, make it possible to actually deploy
and run v3, or may involve significant changes for which we don't want
to have to deal with backwards compatability.

* refactor config loading (jeblair)
* protected flag (inherit only within this project) (jeblair)
* refactor zuul_stream and add testing (mordred)
* getting-started documentation (leifmadsen)
* demonstrate openstack-infra reporting on github
* cross-source dependencies
* add command socket to scheduler and merger for consistent start/stop
* finish git driver
* standardize javascript tooling

------ v3.0 release --------

Yay!  After we release...

Medium Term
-----------

Once the initial v3 release is out the door, there are some things that
we have been planning on for a while and should work on to improve the
v3 story.  These should be straightforward to implement, but these don't
need to hold up the release and can easily fit into v3.1.

* add line comment support to reporters
* gerrit ci reporting (2.14)
* add cleanup jobs (jobs that always run even if parents fail)
* automatic job doc generation

Long Term / Design
------------------

Some of these are items that we should either discuss a bit further
before implementing, but most of them probably warrant an proposal in
infra-specs so we can flesh out the design before we start work.

* gerrit ingestion via separate process?
* per-job artifact location
* need way for admin to trigger a single job (not just a buildset)
* nodepool backends
* nodepool label access (tenant/project label restrictions?)
* nodepool tenant awareness?
* nodepool rest api alignment?
* selinux domains
* fedmesg driver (trigger/reporter)
* mqtt driver (trigger/reporter)
* nodepool status ui?

How does this look?

-Jim