Open Stack

On 12/20/2018 8:02 AM, Bence Romsics wrote:
> I like the idea of a feature flag, however technically 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.
> Therefore I'd suggest adding the feature flag to nova to keep this
> usage possible.

Can't the resource_request part of this be controlled via policy rules 
or something similar? If neutron were using microversions, users would 
have to opt into this new QoS bandwidth behavior and nova, as a client, 
would also have to request that information about each port from neutron 
to know if it's even available in the neutron server version they are 
talking to. Anyway, microversions aside, it's not clear to me why a 
neutron API extension doesn't control if this new field is added to the 
port resource response? 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?

-- 

Thanks,

Matt