[openstack-dev] [Tripleo] Automating role generation

Janki Chhatbar jankihc91 at gmail.com
Fri Sep 21 23:21:52 UTC 2018


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180922/fc76a274/attachment.html>


More information about the OpenStack-dev mailing list