<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Jul 27, 2015 at 4:58 PM Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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></blockquote><div><br></div><div>And people script against that CLI all. the. time. </div><div><br></div><div>Is it pretty? No. But is it something that people do? Yep. </div><div><br></div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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></blockquote><div><br></div><div>"if you want to pin the version" != "all users must explicitly specify the version"</div><div><br></div><div>I believe Jim is advocating for the latter. I'm advocating for the former.</div><div><br></div><div><br></div><div>-Deva</div><div> </div></div></div>