Adding this to future features. On Mon, Feb 22, 2016 at 8:33 PM, Bogdan Dobrelya <bdobre...@mirantis.com> wrote:
> On 22.02.2016 10:28, Kyrylo Galanov wrote: > > Would namespaces be compatible with existing plugins? > > It should be, if the default namespace will be "core" > > > > > On Mon, Feb 22, 2016 at 7:33 PM, Bogdan Dobrelya <bdobre...@mirantis.com > > <mailto:bdobre...@mirantis.com>> wrote: > > > > On 20.02.2016 10:29, Evgeniy L wrote: > > > 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). > > > > > > > Big +1 to namespaces > > > > > Thanks, > > > > > > On Fri, Feb 19, 2016 at 6:02 PM, Aleksandr Didenko > > > <adide...@mirantis.com <mailto:adide...@mirantis.com> > > <mailto:adide...@mirantis.com <mailto: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 <mailto:bgaiful...@mirantis.com> > > <mailto:bgaiful...@mirantis.com <mailto:bgaiful...@mirantis.com>>> > > wrote: > > > > > > > > > > On 19 Feb 2016, at 17:09, Igor Kalnitsky > > > <ikalnit...@mirantis.com <mailto:ikalnit...@mirantis.com> > > <mailto:ikalnit...@mirantis.com <mailto: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 <mailto:bgaiful...@mirantis.com > > > > <mailto:bgaiful...@mirantis.com <mailto: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 <mailto:kgala...@mirantis.com> > > <mailto:kgala...@mirantis.com <mailto: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 <mailto:ikalnit...@mirantis.com> > > <mailto: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> > > <mailto: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/ > > > >>>> > > > >>>> 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://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://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 > > > >> > > > >> > > > >> > > > > __________________________________________________________________________ > > > >> 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://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://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 > > > >> > > > > > > > > > > > > __________________________________________________________________________ > > > > 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://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://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 > > > > > > > > > > > > > __________________________________________________________________________ > > > 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://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > -- > > Best regards, > > Bogdan Dobrelya, > > Irc #bogdando > > > > > __________________________________________________________________________ > > 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 > > > > > > > > > > > __________________________________________________________________________ > > 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 > > > > > -- > Best regards, > Bogdan Dobrelya, > Irc #bogdando > > __________________________________________________________________________ > 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
