Open Stack

On Tue, Apr 16, 2019 at 5:15 PM, Alex Xu <soulxu at gmail.com> wrote:
> 
> 
> Balázs Gibizer <balazs.gibizer at ericsson.com> 
> 于2019年4月10日周三 下午10:59写道：
>> 
>> 
>> 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.
> 
> Maybe the problem isn't "traits on RP that are not providing 
> resources", the problem is we don't count the resources, those traits 
> are attach to, in the compute node. So all those virt driver 
> capability traits are talking about the capability of VM (or say VM 
> resources). But we don't count the number of VM, so we won't have 
> inventory for the VM. The compute node is using the VM(or BM, but 
> just use VM as example here) to provide the compute resources. So I 
> think it is ok to attach those traits to the RP which provides VCPU 
> resource.

I'm not sure I understand your proposal. Would you introduce a VM 
resource and then allocate 1 of that resource for each VM?

Cheers,
gibi