Open Stack

On Wed, Apr 10, 2019 at 3:38 PM, Eric Fried <openstack at fried.cc> wrote:
>>  Since providers can be nested a provider can be a strucutral 
>> element in
>>  a nested tree without providing resources.
> 
> This.
> 
> 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.

Good point. I agree that the COMPUTE_TRUSTED_CERTS logically belong to
the root RP of the compute node.
So we have a specific use case: COMPUTE_TRUSTED_CERTS + NUMA requires 
placement to support traits on RPs that are not providing resources. 
Will in this case VCPU and MEMORY_MB always requested in the unnumbered 
group still? Or there are cases when those resources are requested in a 
numbered group? If the alter then we have a use case to support request 
groups in a_c query that only requires a trait COMPUTE_TRUSTED_CERTS 
but does not require any resoruces.


>>  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:
> https://review.openstack.org/650476
> 
> 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.

I don't want to delay the developement of this feature. I would like to 
see that we implement a certain feature in placement because it is 
needed for specific use case for a specific consumer of placement. So 
if the above discovered use case (COMPUTE_TRUSTED_CERTS + NUMA) are 
valid then I have no problem adding the necessary changes to placement 
to make this use case doable in nova.

Cheers,
gibi

> 
> efried
> .
>