Microversion negotiation support

[Dmitry Tantsur]

I suggest osc-placement implements some kind of microversion negotiation to avoid users seeing this:

 $ openstack resource provider list --resource CUSTOM_BAREMETAL=1
 Operation or argument is not supported with version 1.0

This is quite obvious for people well familiar with microversioning and is extremely confusing for everyone else. This message, by the way, is particularly bad because it does not mention the expected version. It gives an unprepared user an impression that the server does not support the operation. To top it all, "latest" is not supported by OSC.

In ironicclient we implement the negotiation as picking by default the highest microversion that both the server and the client support (you need to keep track of client support, of course). I recommend osc-placement takes the same approach.

[Ed Leafe (ed-leafe)]

One of the primary reasons for designing microversions the way they are is that a user should never receive different results (structure, not data, of course) when making the same request. Always getting 'latest' means that if a new microversion is introduced that alters a response, the user will automatically get this new structure that they may not be able to parse.

I understand the convenience argument, but as a compromise I would suggest making this behavior very explicitly opt-in.

[Matt Riedemann (mriedem)]

The CLI is not a bash SDK so like the nova CLI I think it is much nicer to do the client side version negotiation and use the latest available in the client and server *on the CLI*. Explicitly needing to opt in is a must for SDKs, but I don't think we should be consider the CLI an SDK, and it's been one of the main knocks against the OSC CLI since the user *has* to know the microversions for each command and it's a pain in the butt.

[Matt Riedemann (mriedem)]

I think we could probably could make some incremental improvement on this:

> This message, by the way, is particularly bad because it does not mention the expected version.

I totally agree there, and we should be able to provide some detail about the required minimum microversion in checks like this, at least for the >= case.

[Matt Riedemann (mriedem)]

I've moved this to storyboard:

https://storyboard.openstack.org/#!/story/2005448