Sylvain and I were talking about how he's going to work placement
microversion requests into his filter scheduler patch [1]. He needs to
make requests to the placement API with microversion 1.4 [2] or later
for resource provider filtering on specific resource classes like VCPU
and MEMORY_MB.
The question was what happens if microversion 1.4 isn't available in the
placement API, i.e. the nova-scheduler is running Ocata code now but the
placement service is running Newton still.
Our rolling upgrades doc [3] says:
"It is safest to start nova-conductor first and nova-api last."
But since placement is bundled with n-api that would cause issues since
n-sch now depends on the n-api code.
If you package the placement service separately from the nova-api
service then this is probably not an issue. You can still roll out n-api
last and restart it last (for control services), and just make sure that
placement is upgraded before nova-scheduler (we need to be clear about
that in [3]).
But do we have any other issues if they are not packaged separately? Is
it possible to install the new code, but still only restart the
placement service before nova-api? I believe it is, but want to ask this
out loud.
I think we're probably OK here but I wanted to ask this out loud and
make sure everyone is aware and can think about this as we're a week
from feature freeze. We also need to look into devstack/grenade because
I'm fairly certain that we upgrade n-sch *before* placement in a grenade
run which will make any issues here very obvious in [1].
[1] https://review.openstack.org/#/c/417961/
[2]
http://docs.openstack.org/developer/nova/placement.html#filter-resource-providers-having-requested-resource-capacity
[3]
http://docs.openstack.org/developer/nova/upgrade.html#rolling-upgrade-process
--
Thanks,
Matt Riedemann
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
