2017-01-19 23:43 GMT+08:00 Sylvain Bauza <sba...@redhat.com>: > > > Le 19/01/2017 16:27, Matt Riedemann a écrit : > > 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 > > > > > > I thought out loud in the nova channel at the following possibility : > since we always ask to upgrade n-cpus *AFTER* upgrading our other > services, we could imagine to allow the nova-scheduler gently accept to > have a placement service be Newton *UNLESS* you have Ocata computes. > > On other technical words, the scheduler getting a response from the > placement service is an hard requirement for Ocata. That said, if the > response code is a 400 with a message saying that the schema is > incorrect, it would be checking the max version of all the computes and > then : > - either the max version is Newton and then call back the > ComputeNodeList.get_all() for getting the list of nodes > - or, the max version is Ocata (at least one node is upgraded), and > then we would throw a NoValidHosts >
Emm...when you request a Microversion which didn't support by the service, you will get 406 response. Then you will know the placement is old. Then you needn't check the version of computes? > > That way, the upgrade path would be : > 1/ upgrade your conductor > 2/ upgrade all your other services but n-cpus (we could upgrade and > restart n-sch before n-api, that would still work, or the contrary would > be fine too) > 3/ rolling upgrade your n-cpus > > I think we would keep then the existing upgrade path and we would still > have the placement service be mandatory for Ocata. > > Thoughts ? > -Sylvain > > __________________________________________________________________________ > 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 >
__________________________________________________________________________ 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
