[openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade
Sean Dague
sean at dague.net
Fri Nov 13 12:42:12 UTC 2015
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.
-Sean
--
Sean Dague
http://dague.net
More information about the OpenStack-dev
mailing list