On Tue, Jul 28, 2015 at 09:19:46PM +0000, Devananda van der Veen wrote:
> On Tue, Jul 28, 2015 at 1:57 PM Jim Rollenhagen <j...@jimrollenhagen.com>
> wrote:
>
> > On Tue, Jul 28, 2015 at 08:23:34PM +0000, Devananda van der Veen wrote:
> > > On Mon, Jul 27, 2015 at 4:58 PM Sean Dague <s...@dague.net> wrote:
> > >
> > > > 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.
> > > >
> > > >
> > > And people script against that CLI all. the. time.
> > >
> > > Is it pretty? No. But is it something that people do? Yep.
> > >
> > > Does that mean we should try to care? Yea, I think so, and I think that
> > > means we should try to avoid breaking it when reasonably possible.
> > >
> > >
> > > > If you want to pin things, explicitly, like jroll said, do that. And
> > > > microversions lets you until your clouds uplift past your legacy code.
> > > >
> > >
> > > "if you want to pin the version" != "all users must explicitly specify
> > the
> > > version"
> > >
> > > I believe Jim is advocating for the latter. I'm advocating for the
> > former.
> >
> > The problem that I'm now seeing is you're advocating not just that
> > people should be able to pin a version. You're advocating for:
> >
> > 1. People don't need to pin the version. Fine.
> > 1.1. Side note: perhaps you're actually advocating for "people should
> > not need to pin the version"? It's starting to sound that way.
> > 2. The client should always default to the most recent compatible
> > version. Fine.
> > 3. We should never break a user. Fine.
> > 4. 1-3 must all be true always. Not fine.
> >
> > We can't reasonably make progress while having the latest API version be
> > compatible with the previous API version. The combination above breaks
> > down when we also want to continue to produce software (preferably
> > quickly). We need to let one of those things go; they can't all be true
> > at the same time.
> >
> > I think the best thing to let go is 1 or 2, personally. Where we are
> > today is letting 3 go, and that's why we're stuck here.
> >
> >
> Mmmm, close. I think I expanded on that in my last email (replying to
> Dmitry) ... but... tldr;
>
> 1. yes
> 2. no -- the client should default to the minimum supported version. We got
> that wrong previously, and that's what is hurting us now.
So if we do this, simply shipping the code doesn't break anyone. Nobody
has disagreed on this yet, best I can tell.
So let's ship some code. :)
// jim
> 3. not quite -- we should be very intentional when ever we're going to
> break a user AND we should only do it when there is no other option AND we
> must provide a lot of warning and deprecation period.
>
> -Deva
>
>
>
> > // jim
> >
> > >
> > >
> > > -Deva
> >
> > >
> > __________________________________________________________________________
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
