Open Stack

> 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