[openstack-dev] [TripleO][Heat] Tuskar v. Heat responsibilities
jason.dobies at redhat.com
Mon Jun 29 14:12:10 UTC 2015
>>> We could do likewise in the environment:
>>> OS::TripleO::ControllerConfig: puppet/controller-config.yaml
>>> - 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
>> 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.
More information about the OpenStack-dev