osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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 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
> > .
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190416/0edb4b89/attachment-0001.html>