Open Stack

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