Open Stack

On Fri, 2019-06-14 at 08:37 +0000, Shewale, Bhagyashri wrote:
> >> that is incorrect both a and by will be returned. the spec states
> that for host A we report an inventory of 4 VCPUs and
> >> an inventory of 4 PCPUs and host B will have 1 inventory of 4
> PCPUs so both host will be returned assuming
> >> $<no. of cpus> <=4
> 
> Means if ``vcpu_pin_set`` is set in previous release then report both
> VCPU and PCPU as inventory (in Train) but this seems contradictory
> for example:
> 
> On Stein, 
> 
> Configuration on compute node A:
> vcpu_pin_set=0-3 (This will report 4 VCPUs inventory in placement
> database)
> 
> On Train:
> vcpu_pin_set=0-3
> 
> The inventory will be reported as 4 VCPUs and 4 PCPUs in the
> placement db
> 
> Now say user wants to create instances as below:
> Flavor having extra specs (resources:PCPU=1), instance A
> Flavor having extra specs (resources:VCPU=1), instance B
> 
> For both instance requests, placement will return compute Node A.
> Instance A:  will be pinned to say 0 CPU
> Instance B:  will float on 0-3

This is not a serious issue. This is very similar to what will happen
today if you don't use host aggregrates to isolate NUMA-based instances
from non-NUMA-based instances. If you can assume that operators are
using host aggregates to separate pinned and unpinned instance, then
the VCPU inventory of a host in the 'pinned' aggregrate will never be
consumed and vice versa.

> To resolve above issue, I think it’s possible to detect whether the
> compute node was configured to be used for pinned instances if
> ``NumaTopology`` ``pinned_cpus`` attribute is not empty. In that
> case, vcpu_pin_set will be reported as PCPU otherwise VCPU.

This only works if the host already has instances on it. If you've a
deployment with 100 hosts and 82 of them have instances on there at the
time of upgrade, then 82 will start reporting PCPU inventory and 18
will continue reporting just VCPU inventory. We thought long and hard
about this and there is no good heuristic we can use to separate hosts
that should report PCPUs from those that should report VCPUs. That's
why we said we'll report both and hope that host aggregrates are
configured correctly. If host aggregrates aren't configured, then
things are no more broken than before but at least the operator will
now get warnings (above missing 'cpu_dedicated_set' options).

As before, please push some of this code up so we can start reviewing
it.

Stephen