Open Stack

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160219/621ad695/attachment.html>