+1 to use wildcards for common tasks like netconfig and setup repositories. This tasks should run on all nodes and it does not matter, the node has role from plugin or core-role. In my opinion we should one approach for basic configuration of node.
Regards, Bulat Gaifullin Mirantis Inc. > On 19 Feb 2016, at 13:36, Kyrylo Galanov <kgala...@mirantis.com> wrote: > > Hi, > > So who is voting for the path to be abandoned? > > By the way, there is already a task running by the wildcard: > https://github.com/openstack/fuel-library/blob/master/deployment/puppet/osnailyfacter/modular/fuel_pkgs/tasks.yaml#L4 > > <https://github.com/openstack/fuel-library/blob/master/deployment/puppet/osnailyfacter/modular/fuel_pkgs/tasks.yaml#L4> > However, it this case it might work with plugins. > > Best regards, > Kyrylo > > On Fri, Feb 19, 2016 at 1:09 AM, Igor Kalnitsky <ikalnit...@mirantis.com > <mailto:ikalnit...@mirantis.com>> wrote: > Hey Kyrylo, > > As it was mentioned in the review: you're about to break roles defined > by plugins. That's not good move, I believe. > > Regarding 'exclude' directive, I have no idea what you're talking > about. We don't support it now, and, anyway, there should be no > difference between roles defined by plugins and core roles. > > - Igor > > On Thu, Feb 18, 2016 at 12:53 PM, Kyrylo Galanov <kgala...@mirantis.com > <mailto:kgala...@mirantis.com>> wrote: > > Hello, > > > > We are about to switch to wildcards instead of listing all groups in tasks > > explicitly [0]. > > This change must make deployment process more obvious for developers. > > However, it might lead to confusion when new groups are added either by > > plugin or fuel team in future. > > > > As mention by Bogdan, it is possible to use 'exclude' directive to mitigate > > the risk. > > Any thoughts on the topic are appreciated. > > > > > > [0] https://review.openstack.org/#/c/273596/ > > <https://review.openstack.org/#/c/273596/> > > > > Best regards, > > Kyrylo > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > <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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <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 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
