<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-01-19 23:43 GMT+08:00 Sylvain Bauza <span dir="ltr"><<a href="mailto:sbauza@redhat.com" target="_blank">sbauza@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
Le 19/01/2017 16:27, Matt Riedemann a écrit :<br>
> Sylvain and I were talking about how he's going to work placement<br>
> microversion requests into his filter scheduler patch [1]. He needs to<br>
> make requests to the placement API with microversion 1.4 [2] or later<br>
> for resource provider filtering on specific resource classes like VCPU<br>
> and MEMORY_MB.<br>
><br>
> The question was what happens if microversion 1.4 isn't available in the<br>
> placement API, i.e. the nova-scheduler is running Ocata code now but the<br>
> placement service is running Newton still.<br>
><br>
> Our rolling upgrades doc [3] says:<br>
><br>
> "It is safest to start nova-conductor first and nova-api last."<br>
><br>
> But since placement is bundled with n-api that would cause issues since<br>
> n-sch now depends on the n-api code.<br>
><br>
> If you package the placement service separately from the nova-api<br>
> service then this is probably not an issue. You can still roll out n-api<br>
> last and restart it last (for control services), and just make sure that<br>
> placement is upgraded before nova-scheduler (we need to be clear about<br>
> that in [3]).<br>
><br>
> But do we have any other issues if they are not packaged separately? Is<br>
> it possible to install the new code, but still only restart the<br>
> placement service before nova-api? I believe it is, but want to ask this<br>
> out loud.<br>
><br>
> I think we're probably OK here but I wanted to ask this out loud and<br>
> make sure everyone is aware and can think about this as we're a week<br>
> from feature freeze. We also need to look into devstack/grenade because<br>
> I'm fairly certain that we upgrade n-sch *before* placement in a grenade<br>
> run which will make any issues here very obvious in [1].<br>
><br>
> [1] <a href="https://review.openstack.org/#/c/417961/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/417961/</a><br>
> [2]<br>
> <a href="http://docs.openstack.org/developer/nova/placement.html#filter-resource-providers-having-requested-resource-capacity" rel="noreferrer" target="_blank">http://docs.openstack.org/<wbr>developer/nova/placement.html#<wbr>filter-resource-providers-<wbr>having-requested-resource-<wbr>capacity</a><br>
><br>
> [3]<br>
> <a href="http://docs.openstack.org/developer/nova/upgrade.html#rolling-upgrade-process" rel="noreferrer" target="_blank">http://docs.openstack.org/<wbr>developer/nova/upgrade.html#<wbr>rolling-upgrade-process</a><br>
><br>
><br>
<br>
</div></div>I thought out loud in the nova channel at the following possibility :<br>
since we always ask to upgrade n-cpus *AFTER* upgrading our other<br>
services, we could imagine to allow the nova-scheduler gently accept to<br>
have a placement service be Newton *UNLESS* you have Ocata computes.<br>
<br>
On other technical words, the scheduler getting a response from the<br>
placement service is an hard requirement for Ocata. That said, if the<br>
response code is a 400 with a message saying that the schema is<br>
incorrect, it would be checking the max version of all the computes and<br>
then :<br>
 - either the max version is Newton and then call back the<br>
ComputeNodeList.get_all() for getting the list of nodes<br>
 - or, the max version is Ocata (at least one node is upgraded), and<br>
then we would throw a NoValidHosts<br></blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
That way, the upgrade path would be :<br>
 1/ upgrade your conductor<br>
 2/ upgrade all your other services but n-cpus (we could upgrade and<br>
restart n-sch before n-api, that would still work, or the contrary would<br>
be fine too)<br>
 3/ rolling upgrade your n-cpus<br>
<br>
I think we would keep then the existing upgrade path and we would still<br>
have the placement service be mandatory for Ocata.<br>
<br>
Thoughts ?<br>
<span class="HOEnZb"><font color="#888888">-Sylvain<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>