Open Stack

On Jun 7, 2017, at 1:44 PM, Mooney, Sean K <sean.k.mooney at intel.com <mailto:sean.k.mooney at intel.com>> wrote:

> [Mooney, Sean K] neutron will need to use nested resource providers to track
> Network backend specific consumable resources in the future also. One example is
> is hardware offloaded virtual(e.g. vitio/vhost-user) interfaces which due to
> their hardware based implementation are both a finite consumable
> resources and have numa affinity and there for need to track and nested.
> 
> Another example for neutron would be bandwidth based scheduling / sla enforcement
> where we want to guarantee that a specific bandwidth is available on the selected host
> for a vm to consume. From an ovs/vpp/linux bridge perspective this would likely be tracked at
> the physnet level so when selecting a host we would want to ensure that the physent
> is both available from the host and has enough bandwidth available to resever for the instance.


OK, thanks, this is excellent information.

New question: will the placement service always be able to pick an acceptable provider, given that that the request needs X amount of bandwidth? IOW, are there other considerations besides quantitative amount (and possibly traits for qualitative concerns) that placement simply doesn’t know about? The example I have in mind is the case of stack vs. spread, where there are a few available providers that can meet the request. The logic for which one to pick can’t be in placement, though, as it’s a detail of the calling service. In the case of Nova, the assignment of VFs on vNICs usually should be spread, but that is not what placement knows, it’s handled by filters/weighers in Nova’s scheduler.

OK, that was a really long way of asking: will Neutron ever need to be able to determine the “best” choice from a selection of resource providers? Or will the fact that a resource provider has enough of a given resource be all that is needed?


-- Ed Leafe








-- Ed Leafe





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170607/20b68035/attachment.html>