Open Stack

> So the current API behavior is as below:
>
> 2.32: BDM tag and network device tag added.
> 2.33 - 2.36: 'tag' in the BDM disappeared. The network device tag still
> works.
> 2.37: The network device tag disappeared also.

Thanks for the summary. For the visual minded like me, I made some
ASCII art of the above:

http://paste.openstack.org/raw/596225/

> There are few questions we should think about:
>
> 1. Should we fix that by Microversion?
>     Thanks to Chris Dent point that out in the review. I also think we need
> to bump Microversion, which follow the rule of Microversion.

I don't think we have a choice - we'd be adding new API parameters
that didn't exist in, for example, 2.39.

> 2. If we need Microversion, is that something we can do before release?
>     We are very close to the feature freeze. And in normal, we need spec for
> microversion. Maybe we only can do that in Pike. For now we can update the
> API-ref, and microversion history to notice that, maybe a reno also.

I think it's too late before FF to do any functional fixes. I vote we
document our screw up in the api-ref at least, and during Pike we can
merge a new microversion that fixes this mess.

> 2. How can we prevent that happened again?
>    Both of those patches were reviewed multiple cycles. But we still miss
> that. It is worth to think about how to prevent that happened again.
>
>    Talk with Sean. He suggests stop passing plain string version to the
> schema extension point. We should always pass APIVersionRequest object
> instead of plain string. Due to "version == APIVersionRequest('2.32')" is
> always wrong, we should remove the '__eq__'. The developer should always use
> the 'APIVersionRequest.matches' [3] method.

This looks like a smart way to make sure all API version comparisons
are of the less than/greater than kind.

>    That can prevent the first mistake we made. But nothing help for second
> mistake. Currently we only run the test on the specific Microversion for the
> specific interesting point. In the before, the new tests always inherits
> from the previous microversion tests, just like [4]. That can test the old
> API behavior won't be changed in the new microversion. But now, we said that
> is waste, we didn't do that again just like [5]. Should we change that back?

An idea would be to run all functional tests against 2.latest. This
doesn't cover all microversions, but since as time progresses and
2.latest increases, all previous microversions will have been covered
in the past, and it gives us some confidence that we didn't break
anything. This doesn't work for patches that removed an API parameter
for example, so those kinds of changes will have to be an exception.