<div dir="ltr"><div><br></div>Hi!, <div><br></div><div>   In the context of [1] (generic resource pools / scheduling in nova) and [2] (minimum bandwidth guarantees -egress- in neutron), I had a talk a few weeks ago with Jay Pipes, </div><div><br></div><div>   The idea was leveraging the generic resource pools and scheduling mechanisms defined in [1] to find the right hosts and track the total available bandwidth per host (and per host "physical network"), something in neutron (still to be defined where) would notify the new API about the total amount of "NIC_BW_KB" available on every host/physnet.</div><div><br></div><div>   That part is quite clear to me,</div><div><br></div><div>   From [1] I'm not sure which blueprint introduces the ability to schedule based on the resource allocation/availability itself, ("resource-providers-scheduler" seems more like an optimization to the schedule/DB interaction, right?)</div><div><br></div><div>    And, that brings me to another point: at the moment of filtering hosts, nova  I guess, will have the neutron port information, it has to somehow identify if the port is tied to a minimum bandwidth QoS policy.</div><div><br></div><div>    That would require identifying that the port has a "qos_policy_id" attached to it, and then, asking neutron for the specific QoS policy  [3], then look out for a minimum bandwidth rule (still to be defined), and extract the required bandwidth from it.</div><div><br></div><div>   That moves, again some of the responsibility to examine and understand external resources to nova.</div><div><br></div><div>    Could it make sense to make that part pluggable via stevedore?, so we would provide something that takes the "resource id" (for a port in this case) and returns the requirements translated to resource classes (NIC_BW_KB in this case).</div><div><br></div><div><br></div><div>Best regards,</div><div>Miguel Ángel Ajo</div><div><br></div><div><div><br></div><div>[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-February/086371.html">http://lists.openstack.org/pipermail/openstack-dev/2016-February/086371.html</a></div><div>[2] <a href="https://bugs.launchpad.net/neutron/+bug/1560963">https://bugs.launchpad.net/neutron/+bug/1560963</a> </div></div><div>[3] <a href="http://developer.openstack.org/api-ref-networking-v2-ext.html#showPolicy">http://developer.openstack.org/api-ref-networking-v2-ext.html#showPolicy</a></div></div>