On 1/20/2017 4:53 AM, Eoghan Glynn wrote:
Do we also need to be concerned about the placement API "warm-up" time? i.e. if a placement-less newton deployment is upgraded to placement-ful ocata, then would there surely be a short period during which placement is able to respond to the incoming queries from the scheduler, but only with incomplete information since all the computes haven't yet triggered their first reporting cycle? In that case, it wouldn't necessarily lead to a NoValidHost failure on a instance boot request, but rather a potentially faulty placement decision, being based on incomplete information. I mean "faulty" there in the sense of not strictly following the configured scheduling strategy. Is that a concern, or an acceptable short degradation of service? Cheers, Eoghan
That's discussed a bit in this older thread [1]. If placement is up and running but there are no computes checking in yet, then it's going to be a NoValidHost from the filter scheduler because it's not going to fallback to the compute_nodes table.
The nova-status command was written as an upgrade readiness check for this situation [2]. If there are compute nodes in the database (from Newton) but no resource providers in the placement service, then that upgrade check is going to fail.
If it's a fresh install and there are 0 resource providers in the placement service and 0 compute nodes, then the upgrade check passes but provides a reminder about needing to make sure you get the computes configured and registered for placement as you bring them online.
[1] http://lists.openstack.org/pipermail/openstack-dev/2016-December/109060.html [2] https://github.com/openstack/nova/blob/ae753d96281709397dcfe5dd4ff7d6db57f3683e/nova/cmd/status.py#L301
-- Thanks, Matt Riedemann __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
