On Thu, Dec 20, 2018 at 3:02 PM, Bence Romsics <bence.romsics@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