<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 28, 2015 at 5:30 PM, Jim Rollenhagen <span dir="ltr"><<a href="mailto:jim@jimrollenhagen.com" target="_blank">jim@jimrollenhagen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Jul 28, 2015 at 09:19:46PM +0000, Devananda van der Veen wrote:<br>
> On Tue, Jul 28, 2015 at 1:57 PM Jim Rollenhagen <<a href="mailto:jim@jimrollenhagen.com">jim@jimrollenhagen.com</a>><br>
<span class="">> wrote:<br>
><br>
> > On Tue, Jul 28, 2015 at 08:23:34PM +0000, Devananda van der Veen wrote:<br>
</span><div><div class="h5">> > > On Mon, Jul 27, 2015 at 4:58 PM Sean Dague <<a href="mailto:sean@dague.net">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<br>
> > 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<br>
> > way I<br>
> > > > >> can access the API for integration purposes.<br>
> > > > ><br>
> > > > > "Faithful representation of the API" is an interesting way to put<br>
> > it; it<br>
> > > > > is a "faithful representation" either way. This way is a<br>
> > 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<br>
> > 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<br>
> > 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<br>
> > IRONIC_API_VERSION=1.8<br>
> > > > > or whatever would solve this problem. When new versions are<br>
> > 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,<br>
> > 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<br>
> > the<br>
> > > version"<br>
> > ><br>
> > > I believe Jim is advocating for the latter. I'm advocating for the<br>
> > 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>
> ><br>
> Mmmm, close. I think I expanded on that in my last email (replying to<br>
> Dmitry) ... but... tldr;<br>
><br>
> 1. yes<br>
> 2. no -- the client should default to the minimum supported version. We got<br>
> that wrong previously, and that's what is hurting us now.<br>
<br>
</div></div>So if we do this, simply shipping the code doesn't break anyone. Nobody<br>
has disagreed on this yet, best I can tell.<br>
<br>
So let's ship some code. :)<br>
<br>
// jim<br>
<span class=""><br></span></blockquote><div> </div><div>I'm not sure we can just ship some code, unless I've missed something in the discussion, at some point a user/operator workflow could still break if a future user client is upgraded with the current server code.   Now if this is something the Ironic community is willing to accept, as I personally thought was originally the case, then that is another matter.</div><div><br></div><div>My $0.02 is that forcing a workflow change should be handled with a deprecation period while avoiding the hard breaking change for the user workflow, because it is akin to taking away a feature, or in this case, forcing the user to use a feature they may not want nor need.</div><div><br></div><div>What if we revert 523da21cd3f5fc3299f9b91ac6d885f0fb54eddb and 1410e59228c3835cfc4f89db1ec482137a3cfa10 in order to cut a release, then revert the reverts while layering on top a server side fix to remove the hard break for users?<br></div><div><br></div><div>-Julia</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> 3. not quite -- we should be very intentional when ever we're going to<br>
> break a user AND we should only do it when there is no other option AND we<br>
> must provide a lot of warning and deprecation period.<br>
><br>
> -Deva<br>
><br>
><br>
><br>
> > // jim<br>
> ><br>
> > ><br>
> > ><br>
> > > -Deva<br>
> ><br>
> > ><br>
> > __________________________________________________________________________<br>
> > > OpenStack Development Mailing List (not for usage questions)<br>
> > > Unsubscribe:<br>
</span>> > <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>
<span class="">> > > <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>
</span>> > 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>
<span class="">> > <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>
</span>> 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>
<span class="">> <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>
</span>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><br></div></div>