yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #61175
[Bug 1660484] Re: nova-status upgrade check fails if there are no computes reporting into placement
Reviewed: https://review.openstack.org/427499
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=a954bab009c95b48565d06e2d77afb7d7cb0e080
Submitter: Jenkins
Branch: master
commit a954bab009c95b48565d06e2d77afb7d7cb0e080
Author: Matt Riedemann <mriedem.os@xxxxxxxxx>
Date: Tue Jan 31 17:59:53 2017 -0500
nova-status: relax the resource providers check
As of 4660333d0d97d8e00cf290ea1d4ed932f5edc1dc the filter
scheduler will fallback to not using the placement service
if the minimum nova-compute service version in the deployment
is not new enough to ensure the computes are reporting into
the placement service.
This means we need to relax our check for when there are no
resource providers but there are compute nodes, since the filter
scheduler will not fail on that in Ocata. We intend on making
that a hard failure in Pike, at which time we'll need to adjust
nova-status again.
Change-Id: I1e4dae17cf9d1336bf0ca72948b135b02434ba15
Closes-Bug: #1660484
** Changed in: nova
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1660484
Title:
nova-status upgrade check fails if there are no computes reporting
into placement
Status in OpenStack Compute (nova):
Fix Released
Bug description:
I've got a patch:
https://review.openstack.org/#/c/426926/
That's trying to integrated the 'nova-status upgrade check' command
into a grenade run, and it's failing here:
http://logs.openstack.org/26/426926/2/check/gate-grenade-dsvm-neutron-
ubuntu-xenial/8b536f3/logs/grenade.sh.txt.gz#_2017-01-30_22_20_29_466
It's failing because there is 1 compute node in the database (from the
newton-side run of grenade) but no resource providers, which is
because we're running the upgrade check after starting the placement
service but before starting nova-compute with the upgraded ocata code,
which is what gets that compute reporting into the placement service.
I think this check is probably overly strict for Ocata given we will
fallback to the compute_nodes table in the filter scheduler if not all
computes are upgraded to ocata yet per this change:
https://review.openstack.org/#/c/417961/
In Pike, the filter scheduler will not fallback to the compute_nodes
table and will produce a NoValidHost error if there are no compute
resource providers available. At that point, we could make the upgrade
check more strict, but for now we probably just want this to be a
warning or info level result for nova-status.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1660484/+subscriptions
References