Open Stack

On Thu, Dec 20, 2018 at 3:47 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> 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?

The currently proposed Nova implementation only acts if it sees a 
resource request in a neturon port[1]. However the currently proposed 
nova implementation is incomplete as I descibed in my inital mail of 
this thread. So Neutron can send resource request in the ports before 
Nova can fully handle it, which can lead to resource allocation 
inconsistencies. This is why I'm trying to merge the partial support 
(e.g. boot, delete) guarded by a feature flag while the other 
operations (migrate, evacuate) are under developement.

Cheers,
gibi

[1] 
https://review.openstack.org/#/c/567268/41/nova/network/neutronv2/api.py@1873

> 
> Best,
> -jay
>