Open Stack

Hi,
I have re-spin the grenade multimode dvr config [1].

In my understanding, this job would install multinode environment, with L3 agent and metadata agent running on subnode.
Also to take advantage of this setup:
a) Grenade tests should create DVR router as resource,
b) the Tempest smoke tests should interact with DVR feature.

When a) and b) would not use the DVR feature, we would have DVR-aware setup configured, but no real interaction with DVR done.
By default, Grenade jobs are launching the tempest smoke tests only, and no full tempest suit.

To avoid having 2 jobs running Grenade multinode setup, we can enable only the DVR one in check queue.
To have proper interaction with DVR feature, we can adjust the Grenade tests and tempest smoke suit.

Regards,
Artur Korzeniewski
IRC: korzen

[1] https://review.openstack.org/#/c/250215/4

From: Armando M. [mailto:armamig at gmail.com]
Sent: Monday, February 22, 2016 6:01 PM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade - Nova metadata failure



On 22 February 2016 at 08:52, Ihar Hrachyshka <ihrachys at redhat.com<mailto:ihrachys at redhat.com>> wrote:
Armando M. <armamig at gmail.com<mailto:armamig at gmail.com>> wrote:


On 22 February 2016 at 04:56, Ihar Hrachyshka <ihrachys at redhat.com<mailto:ihrachys at redhat.com>> wrote:
Sean M. Collins <sean at coreitpro.com<mailto: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.

Yes, that is staying. Especially considering that's part of the integrate gate on a bunch of other projects. We'll reconsider what to do, once we strengthen our rolling upgrade story.



Ihar

__________________________________________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160223/f77ca262/attachment.html>