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 <jankih...@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 <sha...@redhat.com> wrote: >> >> On Tue, Sep 4, 2018 at 9:48 AM, Jiří Stránský <ji...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev