> 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