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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
