<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 28, 2015 at 1:57 PM Jim Rollenhagen <<a href="mailto:jim@jimrollenhagen.com">jim@jimrollenhagen.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Jul 28, 2015 at 08:23:34PM +0000, Devananda van der Veen wrote:<br>
> On Mon, Jul 27, 2015 at 4:58 PM Sean Dague <<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>> wrote:<br>
><br>
> > On 07/27/2015 07:10 PM, Jim Rollenhagen wrote:<br>
> > > On Mon, Jul 27, 2015 at 03:28:49PM -0700, Clint Byrum wrote:<br>
> > >> Excerpts from Sean Dague's message of 2015-07-27 13:41:20 -0700:<br>
> > >>> So the CLI should actually break less often, and will expose the most<br>
> > >>> functionality you can get out of your cloud.<br>
> > >>><br>
> > >><br>
> > >> What I find odd about this is that I want the CLI to be a faithful<br>
> > >> representation of the API, because many times the CLI is the only way I<br>
> > >> can access the API for integration purposes.<br>
> > ><br>
> > > "Faithful representation of the API" is an interesting way to put it; it<br>
> > > is a "faithful representation" either way. This way is a representation<br>
> > > of the newest state of the API. It sounds like you're expecting a<br>
> > > representation of the oldest state, or the state that you're used to<br>
> > > (the hardest to predict).<br>
> > ><br>
> > >><br>
> > >> So lets say I just want a very simple bash script to do something with<br>
> > >> nodes:<br>
> > >><br>
> > >> id=$(ironic node-create ...|getid)<br>
> > >> while true ; do<br>
> > >>   state=$(ironic node-get $id | get_state)<br>
> > >>   case $state in<br>
> > >>   AVAILABLE)<br>
> > >>     break;;<br>
> > >>   ERROR)<br>
> > >>     # retry or something<br>
> > >>     ;;<br>
> > >>   *)<br>
> > >>     splode("UNKNOWN STATE")<br>
> > >>     ;;<br>
> > >>   esac<br>
> > >> done<br>
> > >><br>
> > >> Then the script is going to start exploding with a CLI that shows me<br>
> > >> ENROLL state.<br>
> > >><br>
> > >> So I'm not sure having the CLI go faster than the python client is a<br>
> > >> great way to avoid breakage. It might be the opposite of that, and that<br>
> > >> might just be a large burden on users.<br>
> > ><br>
> > > I tend to think that folks using the CLI for automation should be<br>
> > > pinning the version in that automation. A quick IRONIC_API_VERSION=1.8<br>
> > > or whatever would solve this problem. When new versions are available,<br>
> > > read the notes for that version and adjust your code as necessary. Or<br>
> > > just leave it at the same version until it breaks. :)<br>
> ><br>
> > Yeh, it's a cli, not a bash API. Having had to maintain devstack<br>
> > exercise code for a while, I'll tell you that the above is just a time<br>
> > bomb waiting to go off. None of the CLIs have that kind of contract, nor<br>
> > should they. Inflicting the bad UX of today on future generations<br>
> > because someone thinks, incorrectly, that it's a bash SDK is not a good<br>
> > trade off.<br>
> ><br>
> ><br>
> And people script against that CLI all. the. time.<br>
><br>
> Is it pretty? No. But is it something that people do? Yep.<br>
><br>
> Does that mean we should try to care? Yea, I think so, and I think that<br>
> means we should try to avoid breaking it when reasonably possible.<br>
><br>
><br>
> > If you want to pin things, explicitly, like jroll said, do that. And<br>
> > microversions lets you until your clouds uplift past your legacy code.<br>
> ><br>
><br>
> "if you want to pin the version" != "all users must explicitly specify the<br>
> version"<br>
><br>
> I believe Jim is advocating for the latter. I'm advocating for the former.<br>
<br>
The problem that I'm now seeing is you're advocating not just that<br>
people should be able to pin a version. You're advocating for:<br>
<br>
1. People don't need to pin the version. Fine.<br>
   1.1. Side note: perhaps you're actually advocating for "people should<br>
        not need to pin the version"? It's starting to sound that way.<br>
2. The client should always default to the most recent compatible<br>
  version. Fine.<br>
3. We should never break a user. Fine.<br>
4. 1-3 must all be true always. Not fine.<br>
<br>
We can't reasonably make progress while having the latest API version be<br>
compatible with the previous API version. The combination above breaks<br>
down when we also want to continue to produce software (preferably<br>
quickly). We need to let one of those things go; they can't all be true<br>
at the same time.<br>
<br>
I think the best thing to let go is 1 or 2, personally. Where we are<br>
today is letting 3 go, and that's why we're stuck here.<br>
<br></blockquote><div><br></div><div>Mmmm, close. I think I expanded on that in my last email (replying to Dmitry) ... but... tldr; </div><div><br></div><div>1. yes</div><div>2. no -- the client should default to the minimum supported version. We got that wrong previously, and that's what is hurting us now.</div><div>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.</div><div><br></div><div>-Deva</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
// jim<br>
<br>
><br>
><br>
> -Deva<br>
<br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div>