[nova] review guide for the bandwidth patches

Bence Romsics bence.romsics at gmail.com
Wed Jan 2 14:20:10 UTC 2019

Hi Matt,

Sorry for the slow response over the winter holidays.

First I have to correct myself:

> On 12/20/2018 8:02 AM, Bence Romsics wrote:
> > ... in neutron we
> > don't directly control the list of extensions loaded. Instead what we
> > control (through configuration) is the list of service plugins loaded.
> > The 'resource_request' extension is implemented by the 'qos' service
> > plugin. But the 'qos' service plugin implements other API extensions
> > and features too. A cloud admin may want to use these other features
> > of the 'qos' service plugin, but not the guaranteed minimum bandwidth.

This is the default behavior, but it can be overcome by a small patch like this:


With a patch like that we could control loading the
port-resource-request extension (and by that the presence of the
resource_request attribute) on its own (independently of all other
extensions implemented by the qos service plugin).

On Thu, Dec 20, 2018 at 6:58 PM Matt Riedemann <mriedemos at gmail.com> wrote:
> Can't the resource_request part of this be controlled via policy rules
> or something similar?

Is this question still relevant given the above? Even if we could
control the resource-request attribute via policy rules wouldn't that
be just as undiscoverable as a config-only feature flag?

> Barring that, are policy rules something that
> could be used for deployers could decide which users can use this
> feature while it's being rolled out?

Using a standalone neutron extension (controlled on its own by a
neutron config option) as a feature flag (and keeping it not loaded by
default until the feature is past experimental) would lessen the
number of cloud deployments (probably to zero) where the experimental
feature is unintentionally exposed.

On the other hand - now that Jay called my attention to the
undiscoverability of feature flags - I realize that this approach is
not enough to distinguish the complete and experimental versions of
the feature, given the experimental version was exposed intentionally.


More information about the openstack-discuss mailing list