[placement][nova][ptg] Resourceless trait filters

Eric Fried openstack at fried.cc
Wed Apr 10 13:38:57 UTC 2019

> Since providers can be nested a provider can be a strucutral element in 
> a nested tree without providing resources.


I wouldn't get too hung up on "a resource provider that doesn't provide
resources". "Resource provider" is just a name of a thing. It doesn't
(can't) exhaustively define what the thing is and does.

> To avoid the trait on an empty RP problem in this case all 
> the traits are added to the device RPs even if some of the traits 
> (CUSTOM_VNIC_TYPE_XXX) are more logically belong to the agnet RP.

Noting that I have at best a cursory understanding of all things
network, this seems okay to me; I can get my brain around a "network
device" having a "VNIC type" trait. However...

> I think the possible solution to move the trait down to the RP that 
> provides the resources that has a capability described by the trait

In Matt's patch, the traits represent capabilities of the virt driver. I
*suppose* you could argue to attach traits like
COMPUTE_NET_ATTACH_INTERFACE to providers of network resources, or
COMPUTE_VOLUME_EXTEND to providers of disk resources (even those are
pretty awkward). But where would you put COMPUTE_TRUSTED_CERTS? And
let's please not contrive non-resource resources to satisfy
architectural purity.

> I think this work should be driven by a specific need, like the NUMA 
> modelling in placement by nova. What is the timeline of NUMA modelling 
> in placement?

Proposes NUMA topology with RPs: https://review.openstack.org/552924
Proposes NUMA affinity for vGPUs: https://review.openstack.org/650963
Spec: Allocation Candidates: Subtree Affinity:

and a bunch of the other specs in flight are affected by NUMA modeling.

We've been building up to this for years. If it doesn't happen in Train,
it'll happen in U. While I agree we shouldn't solve a problem until it's
a problem, I also don't want to another situation like reshaper, where
suddenly at the end of the cycle we realize/remember this nontrivial
thing we need to handle.


More information about the openstack-discuss mailing list