<div dir="ltr"><div class="gmail_extra">On 4 August 2015 at 12:20, Jim Rollenhagen <span dir="ltr"><<a href="mailto:jim@jimrollenhagen.com" target="_blank">jim@jimrollenhagen.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Jul 27, 2015 at 01:35:25PM -0700, Jim Rollenhagen wrote:<br>
><br>
> Now we've landed a patch[0] with a new version (1.11) that is not<br>
> backward compatible. It causes newly added Node objects to begin life in<br>
> the ENROLL state, rather than AVAILABLE. This is a good thing, and<br>
> people should want this! However, it is a breaking change. Automation<br>
> that adds nodes to Ironic will need to do different things after the<br>
> node-create call.<br>
><br>
> Our API versioning scheme makes this opt-in (by specifying the API<br>
> version). However, some folks have a problem with releasing this change<br>
> as-is. The logic is that we might release a client that defaults to 1.11<br>
> or higher, or the user may request 1.12 later to get a new feature, thus<br>
> breaking their application that enrolls nodes.<br>
<br>
</span>So after much deliberation, we took an informal vote in IRC this morning<br>
between 5 out of our 9 cores.<br>
<br>
The question was: "should we do a 1.12 api version that allows the user<br>
to pick begining provision state in (AVAILABLE, ENROLL), defaulting to<br>
AVAILABLE?"<br>
<br>
The results were 3 for no, 2 for yes. So that's the plan.<br>
<br>
Other Ironic cores (Haomeng, Yuriy, Ramesh, Ruby): please chime in if<br>
you have opinions on this. :)<br>
<br>
Otherwise we'll be getting to work on releasing a server as-is in the<br>
next few days.<br>
<span class="HOEnZb"><font color="#888888"><br>
// jim<br>
</font></span><div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div>Hi, sorry for the delay. I vote no. I understand the rationale of trying to do things so that we don't break our users but that's what the versioning is meant for and more importantly -- I think adding the ENROLL state is fairly important wrt the lifecycle of a node. I don't particularly want to hide that and/or let folks opt out of it in the long term.<div><br></div><div>From a reviewer point-of-view, my concern is me trying to remember all the possible permutations/states etc that are possible to make sure that new code doesn't break existing behavior. I haven't thought out whether adding this new API would make that worse or not, but then, I don't really want to have to think about it. So KISS as much as we can! :)</div><div><br></div><div>--ruby</div><div> </div></div></div></div>