On 4.9.2018 08:13, Janki Chhatbar wrote:
Hi
I am looking to automate role file generation in TripleO. The idea is
basically for an operator to create a simple yaml file (operator.yaml, say)
listing services that are needed and then TripleO to generate
Controller.yaml enabling only those services that are mentioned.
For example:
operator.yaml
services:
Glance
OpenDaylight
Neutron ovs agent
I'm not sure it's worth introducing a new file format as such, if the
purpose is essentially to expand e.g. "Glance" into
"OS::TripleO::Services::GlanceApi" and
"OS::TripleO::Services::GlanceRegistry"? It would be another layer of
indirection (additional mental work for the operator who wants to
understand how things work), while the layer doesn't make too much
difference in preparation of the role. At least that's my subjective view.
Then TripleO should
1. Fail because ODL and OVS agent are either-or services
+1 i think having something like this would be useful.
2. After operator.yaml is modified to remove Neutron ovs agent, it should
generate Controller.yaml with below content
ServicesDefault:
- OS::TripleO::Services::GlanceApi
- OS::TripleO::Services::GlanceRegistry
- OS::TripleO::Services::OpenDaylightApi
- OS::TripleO::Services::OpenDaylightOvs
Currently, operator has to manually edit the role file (specially when
deployed with ODL) and I have seen many instances of failing deployment due
to variations of OVS, OVN and ODL services enabled when they are actually
exclusive.
Having validations on the service list would be helpful IMO, e.g. "these
services must not be in one deployment together", "these services must
not be in one role together", "these services must be together", "we
recommend this service to be in every role" (i'm thinking
TripleOPackages, Ntp, ...) etc. But as mentioned above, i think it would
be better if we worked directly with the "OS::TripleO::Services..."
values rather than a new layer of proxy-values.
Additional random related thoughts:
* Operator should still be able to disobey what the validation suggests,
if they decide so.
* Would be nice to have the info about particular services (e.g what
can't be together) specified declaratively somewhere (TripleO's favorite
thing in the world -- YAML?).
* We could start with just one type of validation, e.g. the mutual
exclusivity rule for ODL vs. OVS, but would be nice to have the solution
easily expandable for new rule types.
Thanks for looking into this :)
Jirka
I am willing to spend some cycle on this. What I ask is some clearity on
its feasibility and any other ideas to make this idea into a feature.
__________________________________________________________________________
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
__________________________________________________________________________
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
