Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>