[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.
Agreed.
>
> - 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?
gate-grenade-dsvm-neutron
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.
Ihar
More information about the OpenStack-dev
mailing list