Open Stack

>>> We could do likewise in the environment:
>>>
>>> resource_registry:
>>>    OS::TripleO::ControllerConfig: puppet/controller-config.yaml
>>>    ...
>>>    constraints:
>>>      OS::TripleO::ControllerConfig:
>>>      - allowed_values:
>>>        - puppet/controller-config.yaml,
>>>        - foo/other-config.yaml]
>>>
>>> These constraints would be enforced at stack validation time such that the
>>> environment would be rejected if the optional constraints were not met.
>>
>> I like this approach.
>>
>> Originally, I was thinking it might be cleaner to encode the
>> relationship in the opposite direction. Something like this in
>> puppet/controller-config.yaml:
>>
>> implements:
>>    OS::TripleO::ControllerConfig
>>
>> But then, you leave it up to the external tools (a UI, etc) to know
>> how to discover these implementing templates. If they're explicitly
>> listed in a list as in your example, that helps UI's / API's more
>> easily present these choices. Maybe it could work both ways.
>
> Yeah the strict interface definition is basically the TOSCA approach
> referenced by Thomas in my validation thread, and while I'm not opposed to
> that, it just feels like overkill for this particular problem.
>
> I don't see any mutually exclusive logic here, we could probably consider
> adding resource_registry constraints and still add interfaces later if it
> becomes apparent we really need them - atm I'm just slightly wary of adding
> more complexity to already complex templates, and also on relying on deep
> introspection to match up interfaces (when we've got no deep validation
> capabilities at all in heat atm) vs some simple rules in the environment.
>
> Sounds like we've got enough consensus on this idea to be worth raising a
> spec, I'll do that next week.

I had originally been thinking of it like slagle describes, from the 
child up to the parent as well. What I like about that approach is that 
it achieves a more pluggable model when you think about extensions that 
aren't accepted or applicable in TripleO upstream.

If someone comes along and adds a new ControllerConfig to your above 
example, they have to edit whatever environment you're talking about 
that defines the constraints (I'm call it overcloud-something.yaml for now).

This becomes a problem from a packaging point of view, especially when 
you factor in non-TripleO integrators (without revealing too much inside 
baseball, think partner integrations). How do I add in an extra package 
(RPM, DEB, whatever) that provides that ControllerConfig and have it 
picked up as a valid option?

We don't want to be editing the overcloud-something.yaml because it's 
owned by another package and there's the potential for conflicts if 
multiple extra implementations start stepping on each other.

An interface/discovery sort of mechanism, which I agree is more complex, 
would be easier to work with in those cases.