[openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade - Nova metadata failure

Ihar Hrachyshka ihrachys at redhat.com
Mon Feb 22 16:52:13 UTC 2016

Armando M. <armamig at gmail.com> wrote:

> On 22 February 2016 at 04:56, Ihar Hrachyshka <ihrachys at redhat.com> wrote:
> Sean M. Collins <sean at coreitpro.com> wrote:
> Armando M. wrote:
> Now that the blocking issue has been identified, I filed project-config
> change [1] to enable us to test the Neutron Grenade multinode more
> thoroughly.
> [1] https://review.openstack.org/#/c/282428/
> Indeed - I want to profusely thank everyone that I reached out to during
> these past months when I got stuck on this. Ihar, Matt K, Kevin B,
> Armando - this is a huge win.
> -- 
> Sean M. Collins
> Thanks everyone to make that latest push. We are almost there!..
> I guess the next steps are:
> - monitoring the job for a week, making sure it’s stable enough  
> (comparing failure rate to non-partial grenade job?);
> Btw, the job trend is here:
> http://grafana.openstack.org/dashboard/db/neutron-failure-rate?panelId=6&fullscreen
> I'd prefer to wait a little longer. Depending on how things go we may  
> want to make it not until N opens up.


> - if everything goes fine, propose project-config change to make it voting;
> - propose governance patch to enable rolling-upgrade tag for neutron repo  
> (I believe not for *aas repos though?).
> I guess with that we would be able to claim victory for the basic 'server  
> vs. agent’ part of rolling scenario. Right?
> Follow up steps would probably be:
> - look at enabling partial job for DVR flavour;
> That should be only instrumental to see how sane DVR during upgrades is,  
> and proceed in tweaking the existing grenade-multi job in the check queue  
> to be dvr-aware. In other words: I personally wouldn't want to see two  
> grenade jobs in the gate.

Ack, that would be the end goal. There still may be some short time when  
both are in gate.

> - proceed on objectification of neutron db layer to open doors for later  
> mixed server versions in the same cluster.
> Anything I missed?
> Also, what do we do with non-partial flavour of the job? Is it staying?
> What job are you talking about exactly?


It’s not ‘partial’ in that we don’t run mixed versions of components during  
tempest run. It only covers that new code can run using old configuration  
files, and that alembic migrations apply correctly for some limited number  
of so called ‘long standing’ resources like instances created on the ‘old’  
side of grenade.


More information about the OpenStack-dev mailing list