<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="h5"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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</blockquote></div></div></div></div></blockquote></div></div></div></div></div></blockquote><div><br></div><div>After thinking about this some more, I'm not actually going to address Rob's points above. What I want to do is go back and discuss... what do people think about having an API that allows the initial provision state to be specified, for a node that is created in Ironic. I'm assuming that enroll state exists :)</div><div><br></div><div>Earlier today on IRC, Devananda mentioned that "there's a very strong case for allowing a node to be created in any of the stable states (enroll, manageable, available, active)". Maybe he'll elaborate later on this. I know that there's a use case where there is a desire to import nodes (with instances on them) from another system into ironic, and have them be active right away. (They don't want the nodes to go from enroll->verifying->manageable->cleaning!!!->available!!!->active).</div><div><br></div><div>1. What would the default provision state be, if it wasn't specified?</div><div>A. 'available' to be backwards compatible with pre-v1.11</div><div>or</div><div>B. 'enroll' to be consistent with v1.11+</div><div>or</div><div>?</div><div><br></div><div><br></div><div>2. What would it mean to set the initial provision state to something other than 'enroll'?</div><div><br></div><div>manageable</div><div>----------------</div><div>In our state machinery[0], a node goes from enroll -> verifying -> manageable. For manageble to be initial state, does it mean that</div><div>A. whatever is needed for enroll and verifying is done and succeeds (under the hood)</div><div>or</div><div>B. whatever is needed for enroll is done and succeeds (but no verifying)</div><div>or</div><div>C. no enroll or verifying is done, it goes straight to manageble</div><div><br></div><div>I'm fine with A.I'm not sure that B makes sense and I definitely don't think C makes sense. To date, verifying means checking that the conductor can get the power state on the node, to verify the supplied power credentials. I don't think it is a big deal if we skip this step; it just means that the next time some action is taken on the node, it might fail.</div><div><br></div><div>available</div><div>------------</div><div>In our state machinery, a node goes from enroll -> verifying -> manageable -> cleaning -> available. For available to be initial state, does it mean that</div><div>A. whatever is needed for enroll, verifying, cleaning is done and succeeds (under the hood)</div><div>or</div><div>B. whatever is needed for enroll is done and succeeds (but no verifying or cleaning)</div><div>or</div><div>??</div><div><br></div><div>active</div><div>--------</div><div><div>In our state machinery, a node goes from enroll -> verifying -> manageable -> cleaning -> available->deploying->active. For active to be initial state, does it mean that</div><div>A. whatever is needed for enroll, verifying, cleaning, deploying is done and succeeds (under the hood)</div><div>or</div><div>B. whatever is needed for enroll is done and succeeds (but no verifying or cleaning)</div></div><div>or</div><div>C. whatever is needed for enroll and I dunno, any 'takeover' stuff by conductor or whatever node states need to be updated to be in active?</div><div><br></div><div>--ruby</div><div><br></div><div>[0] <a href="http://docs.openstack.org/developer/ironic/dev/states.html">http://docs.openstack.org/developer/ironic/dev/states.html</a></div></div></div></div>