[openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade

Ihar Hrachyshka ihrachys at redhat.com
Fri Nov 13 12:46:50 UTC 2015


Sean Dague <sean at dague.net> wrote:

> On 11/13/2015 04:08 AM, Ihar Hrachyshka wrote:
>> Armando M. <armamig at gmail.com> wrote:
>>
>>> On 12 November 2015 at 20:24, Sean M. Collins <sean at coreitpro.com> wrote:
>>> On Thu, Nov 12, 2015 at 05:55:51PM EST, Ihar Hrachyshka wrote:
>>>> I also believe that the first step to get the job set is making
>>> neutron own
>>>> its grenade future, by migrating to grenade plugin maintained in
>>> neutron
>>>> tree.
>>>
>>> I'd like to see what Sean Dague thinks of this - my worry is that if we
>>> start pulling things into Neutron we lose valuable insight from people
>>> who know a lot about Grenade.
>>>
>>> Not to mention, Sean and I have had conversations about trying to get
>>> Neutron as the default for DevStack - we can't just take our ball and go
>>> in our own corner.
>>>
>>> Agreed. (I feel like) we had a good discussion at the summit about
>>> this: we clearly have key pieces that are and will stay within the
>>> realm of both devstack and grenade.
>>
>> Agreed that it’s worth clarifying with grenade folks what should be
>> included in grenade plugin, and what belongs to core grenade; and where
>> multinode ‘partial’ job stands in this regard.
>
> Ok, I top responded with the details of the job, honestly I think it's
> just a project-config change to get up and running, and then hacking at
> the bugs that fall out.
>
> Much like with devstack, I think that neutron core service configuration
> / upgrade should stay in the tree. We want more people familiar with it,
> and I really do want to get us over to Neutron by default some day
> (hopefully not too far off). I'm quite hopefully of the work Sean
> Collins is doing there.
>
> The advanced services should all be in plugins. I think we fully removed
> them from base grenade testing last cycle.
>
> There are lots of coupling in the set of projects that need to cooperate
> to get computes on the network, so debugging and fixing those issues
> often depends on understanding the whole collection. Having the code
> that does that and the ability to bugfix in one place means we can turn
> around breaks faster. It also means that everyone in the ecosystem
> becomes familiar with all of that by default.

Cool, thanks for clarification. I was under impression that all projects  
should adopt plugins, not just those considered not part of core. Also glad  
to hear it’s a matter of infra patch for a new job. I think we’ll roll it  
from here.

Thanks
Ihar



More information about the OpenStack-dev mailing list