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 <e...@leafe.com> wrote: > On Sep 5, 2017, at 10:02 AM, Andrey Volkov <avol...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Thanks, Andrey Volkov, Software Engineer, Mirantis, Inc.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev