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 _______________________________________________ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
