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