[openstack-dev] [Fuel] Wildcards instead of
Kyrylo Galanov
kgalanov at mirantis.com
Wed Feb 24 09:11:28 UTC 2016
Adding this to future features.
On Mon, Feb 22, 2016 at 8:33 PM, Bogdan Dobrelya <bdobrelia at 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 <bdobrelia at mirantis.com
> > <mailto:bdobrelia at 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
> > > <adidenko at mirantis.com <mailto:adidenko at mirantis.com>
> > <mailto:adidenko at mirantis.com <mailto:adidenko at 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
> > > <bgaifullin at mirantis.com <mailto:bgaifullin at mirantis.com>
> > <mailto:bgaifullin at mirantis.com <mailto:bgaifullin at mirantis.com>>>
> > wrote:
> > >
> > >
> > > > On 19 Feb 2016, at 17:09, Igor Kalnitsky
> > > <ikalnitsky at mirantis.com <mailto:ikalnitsky at mirantis.com>
> > <mailto:ikalnitsky at mirantis.com <mailto:ikalnitsky at 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
> > > > <bgaifullin at mirantis.com <mailto:bgaifullin at mirantis.com
> >
> > <mailto:bgaifullin at mirantis.com <mailto:bgaifullin at 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
> > > <kgalanov at mirantis.com <mailto:kgalanov at mirantis.com>
> > <mailto:kgalanov at mirantis.com <mailto:kgalanov at 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
> > > <ikalnitsky at mirantis.com <mailto:ikalnitsky at mirantis.com>
> > <mailto:ikalnitsky at mirantis.com <mailto:ikalnitsky at 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
> > > <kgalanov at mirantis.com <mailto:kgalanov at mirantis.com>
> > <mailto:kgalanov at mirantis.com <mailto:kgalanov at 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-request at lists.openstack.org?subject:unsubscribe
> > <
> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> > >
> > <
> http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> > <
> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> > >
> > <
> http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> > <
> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> > >
> > <
> http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> > <
> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> > >
> > <
> http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> > <
> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> > >
> > <
> http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> > <
> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> > >
> > <
> http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> > <
> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> > >
> > <
> http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> > <
> http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> > <
> http://OpenStack-dev-request@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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160224/b48f1e60/attachment.html>
More information about the OpenStack-dev
mailing list