Open Stack

On 04/11/2016 11:11 AM, michael mccune wrote:
> please forgive my lack of direct knowledge about the neutron process and
> how this fits in. i'm just commenting from the perspective of someone
> looking at this from the api-wg.
> 
> On 04/11/2016 09:52 AM, Duncan Thomas wrote:
>> So by adding the handling of a header to change the behaviour of the
>> API, you're basically implementing a subset of microversions, with a
>> non-standard header (See the API WG spec on non-proliferation of
>> headers). You'll find it takes much of the work that implementing
>> microversions does, and explodes your API test matrix some more.
>>
>> Sounds like something that should go on hold until microversions is
>> done, assuming that microversions are desired anyway. Standard error
>> messages are not such a big win that they're worth non-standard headers
>> and yet more API weirdness that needs to sit around potentially for a
>> very long time (see the API WG rules on removing APIs, which is
>> basically never)
>>
> 
> i think this advice sounds reasonable. adding a side-channel around
> microversions sounds like work that would itself need a microversion
> bump when it is finally removed ;)
> 
> i also agree with the reasoning about the benefit from the standardized
> error messages. it is nice to get a standard error message produced, but
> i think adding microversions is probably a bigger win in the near term
> because it will make these other transitions smoother.

This really was the motivation in creating microversions in the first
place. There were (and still are) many issues in the API, but we kept
tripping over how the client might be able to discover / ask for newer
features. So we solved the discovery / ask for up front, and now there
is a standard mechanism (through a single monotonic value) of providing
for and asking for the new and better API. And works mostly the same
between the 4 services that have now implemented it.

That's a much better path than inventing a new mechanism entirely.

	-Sean

-- 
Sean Dague
http://dague.net