Re: [openstack-dev] [Tripleo] Automating role generation
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 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 wrote: >> >> On Tue, Sep 4, 2018 at 9:48 AM, Jiří Stránský 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 __
Re: [openstack-dev] [Tripleo] Automating role generation
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 wrote: > On Tue, Sep 4, 2018 at 9:48 AM, Jiří Stránský 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
Re: [openstack-dev] [Tripleo] Automating role generation
On Tue, Sep 4, 2018 at 9:48 AM, Jiří Stránský 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
Re: [openstack-dev] [Tripleo] Automating role generation
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. Thanks for looking into this :) Jirka I am willing to spend some cycle on this. What I ask is some clearity on its feasibility and any other ideas to make this idea into a feature. __ 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
[openstack-dev] [Tripleo] Automating role generation
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 Then TripleO should 1. Fail because ODL and OVS agent are either-or services 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. I am willing to spend some cycle on this. What I ask is some clearity on its feasibility and any other ideas to make this idea into a feature. -- 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
