[placement][nova][ptg] Resourceless trait filters
balazs.gibizer at ericsson.com
Tue Apr 16 15:25:39 UTC 2019
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>
>> >> 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
>> > (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
>> > device" having a "VNIC type" trait. However...
>> >> I think the possible solution to move the trait down to the RP
>> >> provides the resources that has a capability described by the
>> > 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
>> > 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
>> 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
>> 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
>> 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
I'm not sure I understand your proposal. Would you introduce a VM
resource and then allocate 1 of that resource for each VM?
More information about the openstack-discuss