Open Stack

On 11/16/2015 06:57 AM, Korzeniewski, Artur wrote:
> Thanks Sean D. for explanation!
> 
>  
> 
> I’ve taken a look into old Russell patches, and it seems that the
> project-config was already modified by him:
> 
> Add check-grenade-dsvm-partial-ncpu-neutron: (project-config)
> 
> https://review.openstack.org/#/c/189426
> 
> Add check-grenade-dsvm-partial-ncpu-neutron-dvr (project-config)
> 
> https://review.openstack.org/#/c/189727

These are not the project-config changes you want. The old partial
method is deprecated, instead you should be using multinode + grenade
(per the conversation at the top of this thread).

> Another 2 patches are introducing the Neutron partial job to devstack-gate
> 
> Add partial-ncpu-neutron grenade mode (devstack-gate)
> 
> https://review.openstack.org/#/c/189424/
> 
> Add partial-ncpu-neutron-dvr grenade mode (devstack-gate)
> 
> https://review.openstack.org/#/c/189715

Again, you don't want these patches. These are the wrong direction.

> I haven’t tested that yet, but it looks like it does the job.
> 
>  
> 
> Also, there is still one patch in Devstack needed for L3 agent separate
> start/stop:
> 
> Separate start/stop control of the Neutron L3 agent. (Devstack)
> 
> https://review.openstack.org/#/c/189710/

No, we don't need that patch.

> 
>  
> 
> From what Sean D. talked about, following patches should not be resurrected:
> 
> Support partial upgrades of Neutron in DVR mode: (Grenade)
> 
> https://review.openstack.org/#/c/189712
> 
>  Support partial Neutron upgrades. (Grenade)
> 
> https://review.openstack.org/#/c/189417/

No, you don't want those either.

> In order to test the RPC right, we should be able to decouple the
> neutron server from its agents – L2, L3, DHCP and metadata agents.
> 
> Current scenario will let us to test :
> 
> 1.       Legacy:
> 
> a.       Controller & network node: neutron server, L2, L3, Metadata and
> DHCP agents
> 
> b.      Compute node: L2 agent.
> 
> 2.       DVR:
> 
> a.       Controller & network node: neutron server, L2, L3, Metadata and
> DHCP agents
> 
> b.      Compute node: L2, L3, Metadata(?) agents
> 
>  
> 
> We can start with current scenario, but this does not guarantee us to
> test of DHCP RPC.
> 
>  
> 
> The ideal upgrade scenario should look like this:
> 
> 1.       Legacy:
> 
> a.       Controller node: neutron server
> 
> b.      Network node: L2, L3, Metadata and DHCP server
> 
> c.       Compute node: L2 agent
> 
> 2.       DVR:
> 
> a.       Controller node: neutron server
> 
> b.      Network node: L2, L3, Metadata and DHCP server
> 
> c.       Compute node: L2, L3 and Metadata agent
> 
>  
> 
> The job still to be done in order to fully test partial upgrades:
> 
> -          Decouple the DHCP and metadata agent from devstack neutron
> restart
> 
> -          Look through the grenade Neutron code in order to identify if
> we are creating the all the resources critical to test the upgrades
> 
> -          Debug, debug, debug…
> 
>  
> 
> Regards,
> 
> Artur
> 
> *From:*Armando M. [mailto:armamig at gmail.com]
> *Sent:* Friday, November 13, 2015 9:37 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [nova][neutron][upgrade] Grenade
> multinode partial upgrade
> 
>  
> 
>  
> 
>  
> 
> On 13 November 2015 at 11:46, Sean Dague <sean at dague.net
> <mailto:sean at dague.net>> wrote:
> 
>     On 11/13/2015 01:16 PM, Sean M. Collins wrote:
>     > On Fri, Nov 13, 2015 at 07:42:12AM EST, Sean Dague wrote:
>     >> 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.
>     >
>     > Thanks - that was super helpful.
>     >
>     > I'm thinking of working on the following on Monday:
>     >
>     > 1) capture that somewhere in the upgrade docs we're putting
>     together in neutron's devref
>     >
>     > 2) Adding the stanza to project-config to get grenade running for
>     > Neutron
>     >
>     > 3) Take a look at the patches that Armando linked a couple emails back
>     > in this thread.
> 
>     I don't think that any of the patches listed there are needed. This was
>     part of the reason I -2ed that direction in the last cycle. It required
>     a separate special code path for partial upgrade setup which was very
>     synthetic (and honestly kind of confusing to debug).
> 
>  
> 
> I don't disagree. I didn't meant to imply 'resume the patches', I was
> only providing the backdrop.
> 
>  
> 
> 
>     The new approach means if you did upgrade for the all-in-one case, and
>     you did multinode setup with worker processes on the subnode, you just
>     make a config where you do them both at the same time, and you have
>     partial upgrade.
> 
>             -Sean
> 
>     --
>     Sean Dague
>     http://dague.net
> 
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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
> 


-- 
Sean Dague
http://dague.net