Hi, +1 to Igor, plugin developer should be able to granularly define what she/he wants to be executed on the node, without assumptions from our side.
`exclude` - field doesn't look like a good solution to me, it will be hard to support and migrate plugins to newer version OpenStack release. I would suggest to solve it differently, lets define namespaces, which we will be able to use to identify tasks from core, with prefix "std:role-name" or "core:role-name", also in the same way plugin or a group of plugins will be able to define their namespaces "lma:role-name" or "detached:keystone", so for library tasks you will have something like that: groups: ['/std:.*/'] or groups: ['/core:.*/'] It's natural to have such thing, because it's similar to what is in Python/Ruby (modules) or in C++ (namespaces). Thanks, On Fri, Feb 19, 2016 at 6:02 PM, Aleksandr Didenko <adide...@mirantis.com> wrote: > > I vote to abandon it. Let's do not break existing plugins, and do not > > add *undo* tasks for plugin developers. If they want to configure > > network, they'll ask it explicitly. > > +1 to this gentleman. It's safe to add wildcards only to tasks that were > moved from pre/post deployment stages, which were executed everywhere > anyway. > > Regards, > Alex > > On Fri, Feb 19, 2016 at 3:22 PM, Bulat Gaifullin <bgaiful...@mirantis.com> > wrote: > >> >> > On 19 Feb 2016, at 17:09, Igor Kalnitsky <ikalnit...@mirantis.com> >> wrote: >> > >> > Kyrylo G. wrote: >> >> So who is voting for the path to be abandoned? >> > >> > I vote to abandon it. Let's do not break existing plugins, and do not >> > add *undo* tasks for plugin developers. If they want to configure >> > network, they'll ask it explicitly. >> > >> > >> > Kyrylo G. wrote: >> >> 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 >> > >> > Yes, exactly, but the thing is that our original task for setuping >> > repos was executed on all nodes before, including ones provided by >> > plugins. Making it executing on core nodes only may break plugins that >> > rely on it. So generally, it's about backward compatibility. >> > >> > >> > Bulat G. wrote: >> >> This tasks should run on all nodes and it does not matter, the node >> >> has role from plugin or core-role. >> > >> > Nope, they shouldn't. Why do I need to install the following packages >> > >> > 'screen', >> > 'tmux', >> > 'htop', >> > 'tcpdump', >> > 'strace', >> > 'fuel-misc', >> > 'man-db', >> > 'fuel-misc', >> > 'fuel-ha’ >> > >> It is big problem? >> >> > if I have no plans to use them? As a deployer engineer, I'd prefer to >> > keep my role as clear as possible, and decide what to install in my >> > own way. >> >> IMO: The plugin developer wants to install additional applications to >> extend functionality, It do not want configure low-level things, like >> specify some banch of task for configure network, configure repositories >> etc. >> How can we manage new node if network is not configured or fuel-agent is >> not installed? >> >> > >> > >> > On Fri, Feb 19, 2016 at 1:06 PM, Bulat Gaifullin >> > <bgaiful...@mirantis.com> wrote: >> >> +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 >> >> 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> >> >> 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> >> >>> 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/ >> >>>> >> >>>> Best regards, >> >>>> Kyrylo >> >>>> >> >>>> >> >>>> >> __________________________________________________________________________ >> >>>> 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 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 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 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