Open Stack

Mutually exclusive services should be decided based on the used
environment files rather than by the list of the services on a role.
For example, ComputeSriov role can be deployed with ml2-ovs or ml2-odl
or ml2-ovn based on the environment file used for the deploy command.
Looking forward.

Regards,
Saravanan KR
On Sat, Sep 22, 2018 at 4:52 AM Janki Chhatbar <jankihc91 at gmail.com> wrote:
>
> Hi All
>
> As per the discussion at PTG, I have filed a BP [1]. I will push a spec sometime around mid-October.
>
> [1]. https://blueprints.launchpad.net/tripleo/+spec/automatic-role-generation
>
> On Tue, Sep 4, 2018 at 2:56 PM Steven Hardy <shardy at redhat.com> wrote:
>>
>> 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
>>
>> __________________________________________________________________________
>> 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
>
>
>
> --
> Thanking you
>
> Janki Chhatbar
> OpenStack | Docker | SDN
> simplyexplainedblog.wordpress.com
> __________________________________________________________________________
> 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