<div dir="ltr"><div><br></div><div>My opinion:</div><div><br></div><div>- If a new API is desirable by operators who would like to skip a few steps in Ironic before making it active, then we should do it. I mean we should allow them to skip the enroll state and manageable state, thereby giving them an opportunity to land the node in "manageable" or "available" state by default. </div><div><br></div><div>- Default state (by default) should be "enroll" as that's where the state of a node in Ironic begins. May be optionally it can be tweaked in ironic.conf.</div><div><br></div><div>- I don't like the idea to land a node directly in active state. The main reason being it differs from driver to driver, what it takes to bring a node to active and what is required for a take over for the active node. For example, while deploying a partition image (by pxe or virtual media drivers), the uuid of the root partition should be available in the driver_internal_info for take_over to happen. So, it would mean that even for existing drivers, we would need to at least provide a mechanism for writing driver_internal_info from the API which is not desirable. It is very much a valid use case to do import. From first thought, I think we should have a new API endpoint to request such an import and a new method in DeployInterface (not an abstract method) for importing bare metals from another system. The API should allow parameters to be passed from the driver to do the import, optionally requesting to reboot the bare metal after it is imported (to make sure that Ironic can properly manage the node again). The new method in DeployInterface should do what it takes to import the bare metal given the parameters. But, that might be a different story :).</div><div><br></div>Regards,<div>Ramesh<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 19, 2015 at 5:35 AM, 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"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><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></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" target="_blank">http://docs.openstack.org/developer/ironic/dev/states.html</a></div></div></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>
<br></blockquote></div><br></div></div></div>