Open Stack

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. :)

// jim

> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev