<div dir="ltr">Apologies, forgot to add [ironic] to the subject.<br><div class="gmail_extra"><br><div class="gmail_quote">On 18 August 2015 at 13:27, Ruby Loo <span dir="ltr"><<a href="mailto:rlooyahoo@gmail.com" target="_blank">rlooyahoo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I want to start a different thread on this topic because I don't think this is about whether/how to do API microversions. Rather, given that we are going to support microversioning, how to deal with the non-backward compatible change in 1.11 with the ENROLL state (instead of AVAILABLE) being the provision state that a node is in, after being created/registered in ironic.</div><div><br></div><div>(This was from 'Let's talk about API versions, <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-August/072287.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-August/072287.html</a>.)</div><div><br></div><div>I want to think about this before replying but others are more than welcome to reply first so that I may not feel the need to reply :-)</div><div><br></div><div>--ruby</div><div>maybe chop off this and above when replying :-)</div><div><div class="gmail_extra"><br><div class="gmail_quote">On 17 August 2015 at 20:20, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 11 August 2015 at 06:13, Ruby Loo <<a href="mailto:rlooyahoo@gmail.com" target="_blank">rlooyahoo@gmail.com</a>> wrote:<br>
> Hi, sorry for the delay. I vote no. I understand the rationale of trying to<br>
> do things so that we don't break our users but that's what the versioning is<br>
> meant for and more importantly -- I think adding the ENROLL state is fairly<br>
> important wrt the lifecycle of a node. I don't particularly want to hide<br>
> that and/or let folks opt out of it in the long term.<br>
><br>
> From a reviewer point-of-view, my concern is me trying to remember all the<br>
> possible permutations/states etc that are possible to make sure that new<br>
> code doesn't break existing behavior. I haven't thought out whether adding<br>
> this new API would make that worse or not, but then, I don't really want to<br>
> have to think about it. So KISS as much as we can! :)<br>
<br>
</span>I'm a little surprised by this, to be honest.<br>
<br>
Here's why: allowing the initial state to be chosen from<br>
ENROLL/AVAILABLE from the latest version of the API is precisely as<br>
complex as allowing two versions of the API {old, new} where old<br>
creates nodes in  AVAILABLE and new creates nodes in ENROLL. The only<br>
difference I can see is that eventually someday if {old} stops being<br>
supported, then and only then we can go through the code and clean<br>
things up.<br>
<br>
It seems to me that the costs to us of supporting graceful transitions<br>
for users here are:<br>
<br>
1) A new version NEWVER of the API that supports node state being one<br>
of {not supplied, AVAILABLE, ENROLL}, on creation, defaulting to<br>
AVAILABLE when not supplied.<br>
2) Supporting the initial state of AVAILABLE indefinitely rather than<br>
just until we *delete* version 1.10.<br>
3) CD deployments that had rolled forward to 1.11 will need to add the<br>
state parameter to their scripts to move forward to NEWVER.<br>
4) Don't default the client to the veresions between 1.10 and NEWVER<br>
versions at any point.<br>
<br>
That seems like a very small price to pay on our side, and the<br>
benefits for users are that they can opt into the new functionality<br>
when they are ready.<br>
<br>
-Rob<span class="HOEnZb"><font color="#888888"><br>
<span><font color="#888888"><br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com" target="_blank">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<br>
</font></span><div><div><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></font></span></blockquote></div><br></div></div></div>
</blockquote></div><br></div></div>