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

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.

I'm effectively replying to my own e-mail here, but I've expressed these thoughts on the spec and it'd probably be better to continue this train of thought there:


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to