Open Stack

On 07/27/2015 07:10 PM, Jim Rollenhagen wrote:
> On Mon, Jul 27, 2015 at 03:28:49PM -0700, Clint Byrum wrote:
>> Excerpts from Sean Dague's message of 2015-07-27 13:41:20 -0700:
>>> So the CLI should actually break less often, and will expose the most
>>> functionality you can get out of your cloud.
>>>
>>
>> What I find odd about this is that I want the CLI to be a faithful
>> representation of the API, because many times the CLI is the only way I
>> can access the API for integration purposes.
> 
> "Faithful representation of the API" is an interesting way to put it; it
> is a "faithful representation" either way. This way is a representation
> of the newest state of the API. It sounds like you're expecting a
> representation of the oldest state, or the state that you're used to
> (the hardest to predict).
> 
>>
>> So lets say I just want a very simple bash script to do something with
>> nodes:
>>
>> id=$(ironic node-create ...|getid)
>> while true ; do
>>   state=$(ironic node-get $id | get_state)
>>   case $state in
>>   AVAILABLE)
>>     break;;
>>   ERROR)
>>     # retry or something
>>     ;;
>>   *)
>>     splode("UNKNOWN STATE")
>>     ;;
>>   esac
>> done
>>
>> Then the script is going to start exploding with a CLI that shows me
>> ENROLL state.
>>
>> So I'm not sure having the CLI go faster than the python client is a
>> great way to avoid breakage. It might be the opposite of that, and that
>> might just be a large burden on users.
> 
> I tend to think that folks using the CLI for automation should be
> pinning the version in that automation. A quick IRONIC_API_VERSION=1.8
> or whatever would solve this problem. When new versions are available,
> read the notes for that version and adjust your code as necessary. Or
> just leave it at the same version until it breaks. :)

Yeh, it's a cli, not a bash API. Having had to maintain devstack
exercise code for a while, I'll tell you that the above is just a time
bomb waiting to go off. None of the CLIs have that kind of contract, nor
should they. Inflicting the bad UX of today on future generations
because someone thinks, incorrectly, that it's a bash SDK is not a good
trade off.

If you want to pin things, explicitly, like jroll said, do that. And
microversions lets you until your clouds uplift past your legacy code.

	-Sean

-- 
Sean Dague
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150727/9825de99/attachment.pgp>