yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #77623
[Bug 1578989] Re: [RFE] Strict minimum bandwidth support (egress)
Reviewed: https://review.openstack.org/640390
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=252598b08827c0cd5e5c4174f84b4196c59f7493
Submitter: Zuul
Branch: master
commit 252598b08827c0cd5e5c4174f84b4196c59f7493
Author: Bence Romsics <bence.romsics@xxxxxxxxxxxx>
Date: Wed Feb 27 08:41:29 2019 +0100
Networking guide: Guaranteed Minimum Bandwidth
High-level overall and low-level neutron docs for the
Guaranteed Minimum Bandwidth feature.
Change-Id: I27224250956b3b940d6372bd46afbdd11e0ce284
Closes-Bug: #1578989
See-Also: https://review.openstack.org/502306 (nova spec)
See-Also: https://review.openstack.org/508149 (neutron spec)
** Changed in: neutron
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1578989
Title:
[RFE] Strict minimum bandwidth support (egress)
Status in neutron:
Fix Released
Bug description:
This RFE is a follow up of [1] and it's registered only for completion
to provide visibility on the high level plan. - we cannot tackle this
until [1] and [2] are in place. -
Minimum bandwidth support (opposed to bandwidth limiting), guarantees
a port minimum bandwidth when it's neighbours are consuming egress
traffic and can be throttled in favor of the guaranteed port.
Strict minimum bandwidth support requires scheduling cooperation, to
avoid physical interfaces overcommit. This RFE assumes that the
hypervisor side of it is handled as per [1]
Use cases
========
NFV/telcos are interested in this type of rules to make sure functions
don't overcommit computes, and that any spawn of the same architecture
will perform exactly as expected.
CSP could make use of it to provide guaranteed bandwidth for
streaming, etc...
Notes
=====
This depends on the nova generic resource pool framework to be
available [2], an specific resource (attached to compute nodes NIC_BW)
being declared by neutron (as per discovery or admin setting on each
host)
Also, a mechanism for nova scheduler to be able to understand the
amount of resources consumed from a port will be necessary. Either as
a detail that is provided in the port when nova is calling neutron for
port creation/get, or as a separate call [3].
Nova dependencies
=================
Custom resource classes:
Spec: https://review.openstack.org/#/c/312696/
Code: https://review.openstack.org/#/q/topic:bp/custom-resource-classes
Nested resource providers:
Spec: https://review.openstack.org/#/c/386710/
Code: https://review.openstack.org/#/q/topic:bp/nested-resource-providers
for example:
NIC_BW_EGRESS.<physnet>
NIC_BW_INGRESS.<physnet>
[1] https://bugs.launchpad.net/neutron/+bug/1560963
[2] http://lists.openstack.org/pipermail/openstack-dev/2016-February/086371.html
[3] http://lists.openstack.org/pipermail/openstack-dev/2016-April/091928.html
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1578989/+subscriptions
References