[openstack-dev] [Tripleo] Automating role generation
jankihc91 at gmail.com
Fri Sep 21 23:21:52 UTC 2018
As per the discussion at PTG, I have filed a BP . I will push a spec
sometime around mid-October.
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
> > 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
> >> 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
> >> 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
> > be in one role together", "these services must be together", "we
> > 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
> > of proxy-values.
> > Additional random related thoughts:
> > * Operator should still be able to disobey what the validation suggests,
> > they decide so.
> > * Would be nice to have the info about particular services (e.g what
> > be together) specified declaratively somewhere (TripleO's favorite thing
> > 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?
> 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.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
OpenStack | Docker | SDN
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev