Open Stack

On 02/28/2015 12:48 PM, Clint Byrum wrote:
> 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.

Agreed, I think that it's a great idea from a decoupling aspect, and let
projects have more control about how they are validated. Very neat.

	-Sean

-- 
Sean Dague
http://dague.net