[openstack-dev] [nova] Order of n-api (placement) and n-sch upgrades for Ocata

Jay Pipes jaypipes at gmail.com
Thu Jan 19 18:48:27 UTC 2017


On 01/19/2017 12:59 PM, Eoghan Glynn wrote:
> I think Alex is suggesting something different than falling back to the
> legacy behaviour. The ocata scheduler would still roll forward to basing
> its node selection decisions on data provided by the placement API, but
> would be tolerant of the 3 different transient cases that are problematic:
>
>  1. placement API momentarily not running yet
>
>  2. placement API already running, but still on the newton micro-version
>
>  3. placement API already running ocata code, but not yet warmed up
>
> IIUC Alex is suggesting that the nova services themselves are tolerant
> of those transient conditions during the upgrade, rather than requiring
> multiple upgrade toolings to independently force the new ordering
> constraint.
>
> On my superficial understanding, case #3 would require the a freshly
> deployed ocata placement (i.e. when upgraded from a placement-less
> newton deployment) to detect that it's being run for the first time
> (i.e. no providers reported yet) and return say 503s to the scheduler
> queries until enough time has passed for all computes to have reported
> in their inventories & allocations.

As mentioned to Alex, I'm totally cool with the scheduler returning 
failures to the end user for some amount of time while the placement API 
service is upgraded (if the deployment tooling upgraded the schedulers 
before the placement API).

What nobody wants to see is the scheduler *die* due to placement API 
version issues or placement API connectivity. The scheduler should 
remain operational/up, but be logging errors continually in this case.

Best,
-jay



More information about the OpenStack-dev mailing list