Open Stack

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>> 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>> wrote:
> 
> 
>         > On 19 Feb 2016, at 17:09, Igor Kalnitsky
>         <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>> 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>> 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>>
>         >> 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>>
>         >>> 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://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
>         >>
>         >>
>         >>
>         __________________________________________________________________________
>         >> 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://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
> 
> 
>         __________________________________________________________________________
>         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://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