Open Stack

On Tue, Apr 21, 2015 at 1:27 PM, Chris Friesen <chris.friesen at windriver.com>
wrote:

> On 04/21/2015 11:35 AM, Hayes, Graham wrote:
>
>> From: Jay Pipes [jaypipes at gmail.com]
>>> The existing --os-compute-api-version CLI option should be made to take:
>>>
>>>    * 2
>>>    * \d+.\d+
>>>    * "latest"
>>>
>>> And nothing else.
>>>
>>
>  Yes - please don't add a flag to the cli (or the python bindings for
>> that matter)
>>
>
> Isn't a cli flag exactly what Jay was describing?


It is, it already exists, it just needs to be made to properly recognize
the required version strings, which is what Jay was suggesting.


> This should be done via discovery. If a call requires a micro-version
>> that is not deployed - return an error.
>>
>
> I haven't had the pleasure(?) of needing to do this, but wouldn't you need
> to know what API versions are available before you try to do some task?
> (In order to know what actions are available, or what parameters to expect
> to be returned.)
>

When a user needs to know much more about the API than "this is the one
that does Whiz-Bang Feature that I want" then we've failed.  Also, many
users aren't probably going to care about API microversions, more likely to
care that GWclient 2.1.2 is the version they need to use Whiz-Bang since
that's what they'll have control over.


> As I understand it, Jay's proposal is that if you don't specify a version
> you get the default (currently version 2, I think), if you do specify a
> version you get that version, and if you specify "latest" then you get the
> most recent version that the server knows about.


The way we've been headed in other discovery implementations is to
negotiate the highest compatible version between the client and server
unless a specific version requested.  What happens in the client will of
course be client-specific, but as a user I would hope that it either makes
a best effort to fail gracefully or make a lot of noise that includes a
clue as to why it failed.


dt

-- 

Dean Troyer
dtroyer at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150421/8276cb08/attachment.html>