Open Stack

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.

cheers,
gibi

> 
> Cheers,
> Bence
>