Open Stack

Ed,

Thanks for the response.

I'm also interested how those models can be used from two points of view.

First, how I can request the desired configuration. I thought about
some anti-affinity logic based on traits in Placement, but probably
that's not a task for Placement. Solution Jay Pipes proposed [1] is to
make several requests to /allocation_candidates and then combine a new
request from responses.

Second, how complicated it would be to update resource provider structure
if some conditions are changed (port was connected to a different switch).
I agree that simple structure is preferable here, for me having PFs as
resource providers
and VFs as inventories with tags (third option in the previos post) is
closer
to reality than hierarchical resource providers. What do you think?

FYI Eric Fried started an etherpad about generic device management [2].

[1] http://paste.openstack.org/show/620456/
[2]
https://etherpad.openstack.org/p/nova-ptg-queens-generic-device-management


On Wed, Sep 6, 2017 at 11:17 PM, Ed Leafe <ed at leafe.com> wrote:

> On Sep 5, 2017, at 10:02 AM, Andrey Volkov <avolkov at mirantis.com> wrote:
>
> > For example, I have SR-IOV PF with four ports (P_i), two of them are
> > connected to one switch (SW_1) and other two to another (SW_2). I
> > would like to get VFs from distinct ports connected to distinct
> > switches (more details can be found in spec [1]), how it can be
> > modeled with nested resource providers?
>
> You should make it as complicated as it needs to be, but no more. The
> first model nests one deep, while the second goes two levels deep, yet they
> both provide the same granularity for accessing the VFs, so I would go for
> the first. And I’m not sure that we will be able to get the “inherited”
> traits used in the second model implemented any time soon.
>
> -- Ed Leafe
>
>
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks,

Andrey Volkov,
Software Engineer, Mirantis, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170907/7e7637a9/attachment.html>