| 2016-03-23 12:41:49 |
Miguel Angel Ajo |
bug |
|
|
added bug |
| 2016-03-23 12:42:34 |
Miguel Angel Ajo |
description |
The current implementation of bandwidth limiting rules only supports egress bandwidth
limiting.
Use cases
========
There are cases where ingress bandwidth limiting is more important than egress limiting,
for example when the workload of the cloud is mostly a consumer of data (crawlers,
datamining, etc), and administrators need to ensure other workloads won't be affected.
Other example are CSPs which need to plan & allocate the bandwidth provided to
customers.
API/Model impact
===============
The BandwidthLimiting rules will be added a direction field (egress/ingress),
which by default will be egress to match the current behaviour and, therefore
be backward compatible.
Combining egress/ingress would be achieved by including an egress bandwidth limit
and an ingress bandwidth limit. |
The current implementation of bandwidth limiting rules only supports egress bandwidth
limiting.
Use cases
========
There are cases where ingress bandwidth limiting is more important than
egress limiting, for example when the workload of the cloud is mostly a consumer of data (crawlers, datamining, etc), and administrators need to ensure other workloads won't be affected.
Other example are CSPs which need to plan & allocate the bandwidth provided to customers.
API/Model impact
===============
The BandwidthLimiting rules will be added a direction field (egress/ingress), which by default will be egress to match the current behaviour and, therefore
be backward compatible.
Combining egress/ingress would be achieved by including an egress bandwidth limit and an ingress bandwidth limit. |
|
| 2016-03-23 12:42:50 |
Miguel Angel Ajo |
description |
The current implementation of bandwidth limiting rules only supports egress bandwidth
limiting.
Use cases
========
There are cases where ingress bandwidth limiting is more important than
egress limiting, for example when the workload of the cloud is mostly a consumer of data (crawlers, datamining, etc), and administrators need to ensure other workloads won't be affected.
Other example are CSPs which need to plan & allocate the bandwidth provided to customers.
API/Model impact
===============
The BandwidthLimiting rules will be added a direction field (egress/ingress), which by default will be egress to match the current behaviour and, therefore
be backward compatible.
Combining egress/ingress would be achieved by including an egress bandwidth limit and an ingress bandwidth limit. |
The current implementation of bandwidth limiting rules only supports egress bandwidth
limiting.
Use cases
=========
There are cases where ingress bandwidth limiting is more important than
egress limiting, for example when the workload of the cloud is mostly a consumer of data (crawlers, datamining, etc), and administrators need to ensure other workloads won't be affected.
Other example are CSPs which need to plan & allocate the bandwidth provided to customers.
API/Model impact
===============
The BandwidthLimiting rules will be added a direction field (egress/ingress), which by default will be egress to match the current behaviour and, therefore
be backward compatible.
Combining egress/ingress would be achieved by including an egress bandwidth limit and an ingress bandwidth limit. |
|
| 2016-03-23 12:43:15 |
Miguel Angel Ajo |
description |
The current implementation of bandwidth limiting rules only supports egress bandwidth
limiting.
Use cases
=========
There are cases where ingress bandwidth limiting is more important than
egress limiting, for example when the workload of the cloud is mostly a consumer of data (crawlers, datamining, etc), and administrators need to ensure other workloads won't be affected.
Other example are CSPs which need to plan & allocate the bandwidth provided to customers.
API/Model impact
===============
The BandwidthLimiting rules will be added a direction field (egress/ingress), which by default will be egress to match the current behaviour and, therefore
be backward compatible.
Combining egress/ingress would be achieved by including an egress bandwidth limit and an ingress bandwidth limit. |
The current implementation of bandwidth limiting rules only supports egress bandwidth
limiting.
Use cases
=========
There are cases where ingress bandwidth limiting is more important than
egress limiting, for example when the workload of the cloud is mostly a consumer of data (crawlers, datamining, etc), and administrators need to ensure other workloads won't be affected.
Other example are CSPs which need to plan & allocate the bandwidth provided to customers, or provide different levels of network service.
API/Model impact
===============
The BandwidthLimiting rules will be added a direction field (egress/ingress), which by default will be egress to match the current behaviour and, therefore
be backward compatible.
Combining egress/ingress would be achieved by including an egress bandwidth limit and an ingress bandwidth limit. |
|
| 2016-03-23 13:28:44 |
Henry Gessau |
neutron: status |
New |
Confirmed |
|
| 2016-03-23 13:29:00 |
Henry Gessau |
neutron: importance |
Undecided |
Wishlist |
|
| 2016-04-04 14:28:25 |
Slawek Kaplonski |
neutron: assignee |
|
Slawek Kaplonski (slaweq) |
|
| 2016-04-08 21:41:25 |
OpenStack Infra |
neutron: status |
Confirmed |
In Progress |
|
| 2016-04-14 17:12:07 |
Armando Migliaccio |
neutron: status |
In Progress |
Triaged |
|
| 2016-04-14 18:35:17 |
Armando Migliaccio |
tags |
qos rfe |
qos rfe-approved |
|
| 2016-04-14 18:35:45 |
Armando Migliaccio |
neutron: milestone |
|
newton-1 |
|
| 2016-04-14 21:15:53 |
OpenStack Infra |
neutron: status |
Triaged |
In Progress |
|
| 2016-06-03 19:34:54 |
Armando Migliaccio |
neutron: milestone |
newton-1 |
newton-2 |
|
| 2016-07-15 23:34:31 |
Armando Migliaccio |
neutron: milestone |
newton-2 |
newton-3 |
|
| 2016-09-01 20:12:15 |
Armando Migliaccio |
neutron: milestone |
newton-3 |
newton-rc1 |
|
| 2016-09-09 02:28:50 |
Armando Migliaccio |
neutron: milestone |
newton-rc1 |
ocata-1 |
|
| 2016-11-16 22:43:16 |
Armando Migliaccio |
neutron: milestone |
ocata-1 |
ocata-2 |
|
| 2016-12-02 01:40:57 |
Armando Migliaccio |
neutron: milestone |
ocata-2 |
|
|
| 2017-04-14 16:53:41 |
OpenStack Infra |
neutron: assignee |
Slawek Kaplonski (slaweq) |
Rodolfo Alonso (rodolfo-alonso-hernandez) |
|
| 2017-04-14 20:37:15 |
OpenStack Infra |
neutron: assignee |
Rodolfo Alonso (rodolfo-alonso-hernandez) |
Slawek Kaplonski (slaweq) |
|
| 2017-04-18 13:51:51 |
Rodolfo Alonso |
description |
The current implementation of bandwidth limiting rules only supports egress bandwidth
limiting.
Use cases
=========
There are cases where ingress bandwidth limiting is more important than
egress limiting, for example when the workload of the cloud is mostly a consumer of data (crawlers, datamining, etc), and administrators need to ensure other workloads won't be affected.
Other example are CSPs which need to plan & allocate the bandwidth provided to customers, or provide different levels of network service.
API/Model impact
===============
The BandwidthLimiting rules will be added a direction field (egress/ingress), which by default will be egress to match the current behaviour and, therefore
be backward compatible.
Combining egress/ingress would be achieved by including an egress bandwidth limit and an ingress bandwidth limit. |
The current implementation of bandwidth limiting rules only supports egress bandwidth
limiting.
Use cases
=========
There are cases where ingress bandwidth limiting is more important than
egress limiting, for example when the workload of the cloud is mostly a consumer of data (crawlers, datamining, etc), and administrators need to ensure other workloads won't be affected.
Other example are CSPs which need to plan & allocate the bandwidth provided to customers, or provide different levels of network service.
API/Model impact
===============
The BandwidthLimiting rules will be added a direction field (egress/ingress), which by default will be egress to match the current behaviour and, therefore
be backward compatible.
Combining egress/ingress would be achieved by including an egress bandwidth limit and an ingress bandwidth limit.
Additional information
======================
The CLI and SDK modifications are addressed in https://bugs.launchpad.net/python-openstackclient/+bug/1614121 |
|
| 2017-05-23 11:24:20 |
Rodolfo Alonso |
neutron: status |
In Progress |
Fix Committed |
|
| 2017-05-23 11:24:28 |
Rodolfo Alonso |
neutron: status |
Fix Committed |
Fix Released |
|
| 2018-02-28 21:54:05 |
Akihiro Motoki |
neutron: milestone |
|
pike-3 |
|
| 2019-08-26 17:57:01 |
Jorge Niedbalski |
bug task added |
|
neutron (Ubuntu) |
|
| 2019-08-26 18:00:10 |
Jorge Niedbalski |
nominated for series |
|
Ubuntu Xenial |
|
| 2019-08-26 18:00:10 |
Jorge Niedbalski |
bug task added |
|
neutron (Ubuntu Xenial) |
|
| 2019-08-26 18:00:30 |
Jorge Niedbalski |
bug task added |
|
cloud-archive |
|
| 2019-08-26 18:40:44 |
Corey Bryant |
nominated for series |
|
cloud-archive/mitaka |
|
| 2019-08-26 18:40:44 |
Corey Bryant |
bug task added |
|
cloud-archive/mitaka |
|
| 2019-08-26 18:40:44 |
Corey Bryant |
nominated for series |
|
cloud-archive/ocata |
|
| 2019-08-26 18:40:44 |
Corey Bryant |
bug task added |
|
cloud-archive/ocata |
|
| 2019-08-26 19:10:15 |
Corey Bryant |
bug task deleted |
cloud-archive |
|
|
| 2019-08-26 19:10:25 |
Corey Bryant |
bug task deleted |
cloud-archive/mitaka |
|
|
| 2019-08-26 19:10:27 |
Corey Bryant |
bug task deleted |
cloud-archive/ocata |
|
|
| 2019-09-23 17:39:55 |
Corey Bryant |
bug task deleted |
neutron (Ubuntu) |
|
|
| 2019-09-23 17:40:00 |
Corey Bryant |
bug task deleted |
neutron (Ubuntu Xenial) |
|
|
