Open Stack

On Tue, Sep 4, 2018 at 9:48 AM, Jiří Stránský <jistr at redhat.com> wrote:
> 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.

This is similar to how the UI uses the capabilities-map.yaml, so
perhaps we can use that as the place to describe service dependencies
and conflicts?

https://github.com/openstack/tripleo-heat-templates/blob/master/capabilities-map.yaml

Currently this isn't used at all for the CLI, but I can imagine some
kind of wizard interface being useful, e.g you could say enable
"Glance" group and it'd automatically pull in all glance dependencies?

Another thing to mention is this doesn't necessarily have to generate
a new role (although it could), the *Services parameter for existing
roles can be overridden, so it might be simpler to generate an
environment file instead.

Steve