<div dir="ltr"><br><div>Thanks for giving me a chance to vote.  I don't have any experience talking to production/live Ironic using a client and only talk to my own devstack.  Personally I vote for a *no* (for such a 1.12) the reasons that have been cited in the previous threads that</div><div><br></div><div>1) we need users to be aware of API versions (so I also would want them to pin it if they wanted a stable one, so don't default in their automation and keep testing and updating to the newer api versions)</div><div>2) it's already released, and i also tend to consider anything released could already being used right now </div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 4, 2015 at 9:50 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"><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>
__________________________________________________________________________<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>
</div></div></blockquote></div><br></div>