Open Stack

Excerpts from Jay Pipes's message of 2015-02-28 08:41:40 -0800:
> Jim, great stuff. A couple suggestions inline :)
> 
> On 02/26/2015 09:59 AM, James E. Blair wrote:
> > A tenant may optionally specify repos from which it may derive its
> > configuration.  In this manner, a repo may keep its Zuul configuration
> > within its own repo.  This would only happen if the main configuration
> > file specified that it is permitted::
> >
> >    ### main.yaml (continued)
> >    - tenant:
> >        name: random-stackforge-project
> >        include:
> >     - global_config.yaml
> >        repos:
> >     - stackforge/random  # Specific project config is in-repo
> 
> Might I suggest that instead of a repos: YAML block, that instead, the 
> include: YAML block allow URIs. So, to support some random Zuul config 
> in a stackforge repo, you could do:
> 
> include:
>   - global_config.yaml
>   - https://git.openstack.org/stackforge/random/tools/zuul.yml
> 
> That would make the configuration simpler, I think.
> 

I see where you're driving at, but I'm not sure it is what we'd
want. First, the knee jerk is zomg I don't want my service restart
dependent on git.o.o being reachable. But that's not super relevant.

More importantly, having arbitrary remote config doesn't seem like the
goal here. I think what Jim is suggesting is that since Zuul already knows
about repos, that it might also want to dig around in said repos to find
layouts so that we can let projects manage their own layout once infra
has acknowledged that their repo is one that zuul needs to care about.

I usually am for decoupling all the things, but in this case, coupling
provides a level of comfort for the Zuul operator that would express
more succinctly what the operator intends: let this repo manage layouts
for itself.

BTW, having this is really interesting because in theory one can disable
a job that a change breaks in the same patch, or enable a job in the
same change that fixes it. I really like that aspect.