[nova] review guide for the bandwidth patches

melanie witt melwittt at gmail.com
Fri Jan 4 08:48:45 UTC 2019


On Thu, 3 Jan 2019 11:40:22 -0600, Matt Riedemann <mriedemos at gmail.com> 
wrote:
> On 12/28/2018 4:13 AM, Bal√°zs Gibizer wrote:
>> I'm wondering that introducing an API microversion could act like a
>> feature flag I need and at the same time still make the feautre
>> discoverable as you would like to see it. Something like: Create a
>> feature flag in the code but do not put it in the config as a settable
>> flag. Instead add an API microversion patch to the top of the series
>> and when the new version is requested it enables the feature via the
>> feature flag. This API patch can be small and simple enough to
>> cherry-pick to earlier into the series for local end-to-end testing if
>> needed. Also in functional test I can set the flag via a mock so I can
>> add and run functional tests patch by patch.
> 
> That may work. It's not how I would have done this, I would have started
> from the bottom and worked my way up with the end to end functional
> testing at the end, as already noted, but I realize you've been pushing
> this boulder for a couple of releases now so that's not really something
> you want to change at this point.
> 
> I guess the question is should this change have a microversion at all?
> That's been wrestled in the spec review and called out in this thread. I
> don't think a microversion would be *wrong* in any sense and could only
> help with discoverability on the nova side, but am open to other opinions.

Sorry to be late to this discussion, but this brought up in the nova 
meeting today to get more thoughts. I'm going to briefly summarize my 
thoughts here.

IMHO, I think this change should have a microversion, to help with 
discoverability. I'm thinking, how will users be able to detect they're 
able to leverage the new functionality otherwise? A microversion would 
signal the availability. As for dealing with the situation where a user 
specifies an older microversion combined with resource requests, I think 
it should behave similarly to how multiattach works, where the request 
will be rejected straight away if microversion too low + resource 
requests are passed. Current behavior today would be, the resource 
requests are ignored. If we only ignored the resource requests when 
they're passed with an older microversion, it seems like it would be an 
unnecessarily poor UX to have their parameters ignored and likely lead 
them on a debugging journey if and when they realize things aren't 
working the way they expect given the resource requests they specified.

-melanie






More information about the openstack-discuss mailing list