<div dir="ltr">Hi,<div><br></div><div>+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.</div><div><br></div><div>`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.</div><div><br></div><div>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:</div><div><br></div><div>    groups: ['/std:.*/']</div><div><br></div><div>or</div><div><br></div><div>    groups: ['/core:.*/']</div><div><br></div><div>It's natural to have such thing, because it's similar to what is in Python/Ruby (modules) or in C++ (namespaces).</div><div><br></div><div>Thanks,</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 19, 2016 at 6:02 PM, Aleksandr Didenko <span dir="ltr"><<a href="mailto:adidenko@mirantis.com" target="_blank">adidenko@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span class=""><div>> I vote to abandon it. Let's do not break existing plugins, and do not<br>> add *undo* tasks for plugin developers. If they want to configure<br>> network, they'll ask it explicitly.<br><br></div></span>+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.<br><br></div><div>Regards,<br></div><div>Alex<br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 19, 2016 at 3:22 PM, Bulat Gaifullin <span dir="ltr"><<a href="mailto:bgaifullin@mirantis.com" target="_blank">bgaifullin@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br>
> On 19 Feb 2016, at 17:09, Igor Kalnitsky <<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>> wrote:<br>
><br>
> Kyrylo G. wrote:<br>
>> So who is voting for the path to be abandoned?<br>
><br>
> I vote to abandon it. Let's do not break existing plugins, and do not<br>
> add *undo* tasks for plugin developers. If they want to configure<br>
> network, they'll ask it explicitly.<br>
><br>
><br>
> Kyrylo G. wrote:<br>
>> By the way, there is already a task running by the wildcard:<br>
>> <a href="https://github.com/openstack/fuel-library/blob/master/deployment/puppet/osnailyfacter/modular/fuel_pkgs/tasks.yaml#L4" rel="noreferrer" target="_blank">https://github.com/openstack/fuel-library/blob/master/deployment/puppet/osnailyfacter/modular/fuel_pkgs/tasks.yaml#L4</a><br>
><br>
> Yes, exactly, but the thing is that our original task for setuping<br>
> repos was executed on all nodes before, including ones provided by<br>
> plugins. Making it executing on core nodes only may break plugins that<br>
> rely on it. So generally, it's about backward compatibility.<br>
><br>
><br>
> Bulat G. wrote:<br>
>> This tasks should run on all nodes and it does not matter, the node<br>
>> has role from plugin or core-role.<br>
><br>
> Nope, they shouldn't. Why do I need to install the following packages<br>
><br>
>  'screen',<br>
>  'tmux',<br>
>  'htop',<br>
>  'tcpdump',<br>
>  'strace',<br>
>  'fuel-misc',<br>
>  'man-db',<br>
>  'fuel-misc',<br>
</div></div>>  'fuel-ha’<br>
><br>
It is big problem?<br>
<span><br>
> if I have no plans to use them? As a deployer engineer, I'd prefer to<br>
> keep my role as clear as possible, and decide what to install in my<br>
> own way.<br>
<br>
</span>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.<br>
How can we manage new node if network is not configured or fuel-agent is not installed?<br>
<div><div><br>
><br>
><br>
> On Fri, Feb 19, 2016 at 1:06 PM, Bulat Gaifullin<br>
> <<a href="mailto:bgaifullin@mirantis.com" target="_blank">bgaifullin@mirantis.com</a>> wrote:<br>
>> +1 to use wildcards for common tasks like netconfig and setup repositories.<br>
>> This tasks should run on all nodes and it does not matter, the node has role<br>
>> from plugin or core-role.<br>
>> In my opinion we should one approach for basic configuration of node.<br>
>><br>
>> Regards,<br>
>> Bulat Gaifullin<br>
>> Mirantis Inc.<br>
>><br>
>><br>
>><br>
>> On 19 Feb 2016, at 13:36, Kyrylo Galanov <<a href="mailto:kgalanov@mirantis.com" target="_blank">kgalanov@mirantis.com</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> So who is voting for the path to be abandoned?<br>
>><br>
>> By the way, there is already a task running by the wildcard:<br>
>> <a href="https://github.com/openstack/fuel-library/blob/master/deployment/puppet/osnailyfacter/modular/fuel_pkgs/tasks.yaml#L4" rel="noreferrer" target="_blank">https://github.com/openstack/fuel-library/blob/master/deployment/puppet/osnailyfacter/modular/fuel_pkgs/tasks.yaml#L4</a><br>
>> However, it this case it might work with plugins.<br>
>><br>
>> Best regards,<br>
>> Kyrylo<br>
>><br>
>> On Fri, Feb 19, 2016 at 1:09 AM, Igor Kalnitsky <<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>><br>
>> wrote:<br>
>>><br>
>>> Hey Kyrylo,<br>
>>><br>
>>> As it was mentioned in the review: you're about to break roles defined<br>
>>> by plugins. That's not good move, I believe.<br>
>>><br>
>>> Regarding 'exclude' directive, I have no idea what you're talking<br>
>>> about. We don't support it now, and, anyway, there should be no<br>
>>> difference between roles defined by plugins and core roles.<br>
>>><br>
>>> - Igor<br>
>>><br>
>>> On Thu, Feb 18, 2016 at 12:53 PM, Kyrylo Galanov <<a href="mailto:kgalanov@mirantis.com" target="_blank">kgalanov@mirantis.com</a>><br>
>>> wrote:<br>
>>>> Hello,<br>
>>>><br>
>>>> We are about to switch to wildcards instead of listing all groups in<br>
>>>> tasks<br>
>>>> explicitly [0].<br>
>>>> This change must make deployment process more obvious for developers.<br>
>>>> However, it might lead to confusion when new groups are added either by<br>
>>>> plugin or fuel team in future.<br>
>>>><br>
>>>> As mention by Bogdan, it is possible to use 'exclude' directive to<br>
>>>> mitigate<br>
>>>> the risk.<br>
>>>> Any thoughts on the topic are appreciated.<br>
>>>><br>
>>>><br>
>>>> [0] <a href="https://review.openstack.org/#/c/273596/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/273596/</a><br>
>>>><br>
>>>> Best regards,<br>
>>>> Kyrylo<br>
>>>><br>
>>>><br>
>>>> __________________________________________________________________________<br>
>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>> Unsubscribe:<br>
>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>><br>
>>><br>
>>> __________________________________________________________________________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>