Open Stack

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