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
__________________________________________________________________________
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
