[nova] review guide for the bandwidth patches

Jay Pipes jaypipes at gmail.com
Thu Dec 20 14:47:40 UTC 2018


On 12/20/2018 09:33 AM, Balázs Gibizer wrote:
> On Thu, Dec 20, 2018 at 3:02 PM, Bence Romsics
> <bence.romsics at gmail.com> wrote:
>> Hi Gibi,
>>
>>>   However I think we can use the feature flag approach. We can
>>> implement
>>>   and verify everything in the current order without the end user
>>> seeing
>>>   or causing any kind of inconsistencies. The nova implementation is
>>> only
>>>   activated if a neutron port has a resource_request field. This
>>> field is
>>>   added to the neutron API as an API extension. We can mark this
>>>   extension experimental while we are working through the missing
>>> pieces
>>>   of the feature.
>>
>> 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.
> 
> Thanks Bence. I still want to belive that the proper solution for this
> long running implementation is to use a feature flag. Nova has a
> 'workaround' config section that might be used to add a new config
> option as a feature flag similar to the existing
> 'enable_numa_live_migration' option. This way the feature can be
> controller externally.
> 
> Would be good to see the reaction from other Nova developers about this
> approch.

The problem with feature flags is they are not discoverable. As much as 
I hate API extensions, at least they are discoverable.

Is there a reason why we can't just put code into Nova that, upon seeing 
the resource requests, acts on it? Is there a reason it needs to be 
behind a feature flag or even needs to query Neutron for extension 
support? I mean, if it's in the response payload, just use it, right?

Best,
-jay



More information about the openstack-discuss mailing list