<div dir="ltr"><div>Ed, </div><div><br></div><div>Thanks for the response.</div><div><br></div><div>I'm also interested how those models can be used from two points of view.</div><div><br></div><div>First, how I can request the desired configuration. I thought about</div><div>some anti-affinity logic based on traits in Placement, but probably</div><div>that's not a task for Placement. Solution Jay Pipes proposed [1] is to</div><div>make several requests to /allocation_candidates and then combine a new</div><div>request from responses.</div><div><br></div><div>Second, how complicated it would be to update resource provider structure</div><div>if some conditions are changed (port was connected to a different switch).</div><div>I agree that simple structure is preferable here, for me having PFs as resource providers</div><div>and VFs as inventories with tags (third option in the previos post) is closer</div><div>to reality than hierarchical resource providers. What do you think?</div><div><br></div><div>FYI Eric Fried started an etherpad about generic device management [2].</div><div><br></div><div>[1] <a href="http://paste.openstack.org/show/620456/">http://paste.openstack.org/show/620456/</a></div><div>[2] <a href="https://etherpad.openstack.org/p/nova-ptg-queens-generic-device-management">https://etherpad.openstack.org/p/nova-ptg-queens-generic-device-management</a></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 6, 2017 at 11:17 PM, Ed Leafe <span dir="ltr"><<a href="mailto:ed@leafe.com" target="_blank">ed@leafe.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sep 5, 2017, at 10:02 AM, Andrey Volkov <<a href="mailto:avolkov@mirantis.com">avolkov@mirantis.com</a>> wrote:<br>
<br>
> For example, I have SR-IOV PF with four ports (P_i), two of them are<br>
> connected to one switch (SW_1) and other two to another (SW_2). I<br>
> would like to get VFs from distinct ports connected to distinct<br>
> switches (more details can be found in spec [1]), how it can be<br>
> modeled with nested resource providers?<br>
<br>
</span>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.<br>
<br>
-- Ed Leafe<br>
<br>
<br>
<br>
<br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div>Thanks,</div><div><br></div><div>Andrey Volkov,</div><div>Software Engineer, <span style="font-size:12.8px">Mirantis, Inc.</span></div></div></div></div></div></div>
</div>