<div dir="ltr"><div dir="ltr"><div>Hi All<br><br></div>As per the discussion at PTG, I have filed a BP [1]. I will push a spec sometime around mid-October.<br><br>[1]. <a href="https://blueprints.launchpad.net/tripleo/+spec/automatic-role-generation">https://blueprints.launchpad.net/tripleo/+spec/automatic-role-generation</a><br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 4, 2018 at 2:56 PM Steven Hardy <<a href="mailto:shardy@redhat.com">shardy@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Sep 4, 2018 at 9:48 AM, Jiří Stránský <<a href="mailto:jistr@redhat.com" target="_blank">jistr@redhat.com</a>> wrote:<br>
> On 4.9.2018 08:13, Janki Chhatbar wrote:<br>
>><br>
>> Hi<br>
>><br>
>> I am looking to automate role file generation in TripleO. The idea is<br>
>> basically for an operator to create a simple yaml file (operator.yaml,<br>
>> say)<br>
>> listing services that are needed and then TripleO to generate<br>
>> Controller.yaml enabling only those services that are mentioned.<br>
>><br>
>> For example:<br>
>> operator.yaml<br>
>> services:<br>
>>      Glance<br>
>>      OpenDaylight<br>
>>      Neutron ovs agent<br>
><br>
><br>
> I'm not sure it's worth introducing a new file format as such, if the<br>
> purpose is essentially to expand e.g. "Glance" into<br>
> "OS::TripleO::Services::GlanceApi" and<br>
> "OS::TripleO::Services::GlanceRegistry"? It would be another layer of<br>
> indirection (additional mental work for the operator who wants to understand<br>
> how things work), while the layer doesn't make too much difference in<br>
> preparation of the role. At least that's my subjective view.<br>
><br>
>><br>
>> Then TripleO should<br>
>> 1. Fail because ODL and OVS agent are either-or services<br>
><br>
><br>
> +1 i think having something like this would be useful.<br>
><br>
>> 2. After operator.yaml is modified to remove Neutron ovs agent, it should<br>
>> generate Controller.yaml with below content<br>
>><br>
>> ServicesDefault:<br>
>> - OS::TripleO::Services::GlanceApi<br>
>> - OS::TripleO::Services::GlanceRegistry<br>
>> - OS::TripleO::Services::OpenDaylightApi<br>
>> - OS::TripleO::Services::OpenDaylightOvs<br>
>><br>
>> Currently, operator has to manually edit the role file (specially when<br>
>> deployed with ODL) and I have seen many instances of failing deployment<br>
>> due<br>
>> to variations of OVS, OVN and ODL services enabled when they are actually<br>
>> exclusive.<br>
><br>
><br>
> Having validations on the service list would be helpful IMO, e.g. "these<br>
> services must not be in one deployment together", "these services must not<br>
> be in one role together", "these services must be together", "we recommend<br>
> this service to be in every role" (i'm thinking TripleOPackages, Ntp, ...)<br>
> etc. But as mentioned above, i think it would be better if we worked<br>
> directly with the "OS::TripleO::Services..." values rather than a new layer<br>
> of proxy-values.<br>
><br>
> Additional random related thoughts:<br>
><br>
> * Operator should still be able to disobey what the validation suggests, if<br>
> they decide so.<br>
><br>
> * Would be nice to have the info about particular services (e.g what can't<br>
> be together) specified declaratively somewhere (TripleO's favorite thing in<br>
> the world -- YAML?).<br>
><br>
> * We could start with just one type of validation, e.g. the mutual<br>
> exclusivity rule for ODL vs. OVS, but would be nice to have the solution<br>
> easily expandable for new rule types.<br>
<br>
This is similar to how the UI uses the capabilities-map.yaml, so<br>
perhaps we can use that as the place to describe service dependencies<br>
and conflicts?<br>
<br>
<a href="https://github.com/openstack/tripleo-heat-templates/blob/master/capabilities-map.yaml" rel="noreferrer" target="_blank">https://github.com/openstack/tripleo-heat-templates/blob/master/capabilities-map.yaml</a><br>
<br>
Currently this isn't used at all for the CLI, but I can imagine some<br>
kind of wizard interface being useful, e.g you could say enable<br>
"Glance" group and it'd automatically pull in all glance dependencies?<br>
<br>
Another thing to mention is this doesn't necessarily have to generate<br>
a new role (although it could), the *Services parameter for existing<br>
roles can be overridden, so it might be simpler to generate an<br>
environment file instead.<br>
<br>
Steve<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Thanking you<div><br></div><div>Janki Chhatbar</div><div>OpenStack | Docker | SDN</div><div><a href="http://simplyexplainedblog.wordpress.com" target="_blank">simplyexplainedblog.wordpress.com</a></div></div></div></div>