Open Stack

Hi,

> 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 :)
>
> 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).
>

I would like to hear the more elaborated proposal before we start
digging much into this problem.

> 1. What would the default provision state be, if it wasn't specified?
> A. 'available' to be backwards compatible with pre-v1.11
> or
> B. 'enroll' to be consistent with v1.11+
> or
> ?
>
>
> 2. What would it mean to set the initial provision state to something other
> than 'enroll'?
>
> manageable
> ----------------
> In our state machinery[0], a node goes from enroll -> verifying ->
> manageable. For manageble to be initial state, does it mean that
> A. whatever is needed for enroll and verifying is done and succeeds (under
> the hood)
> or
> B. whatever is needed for enroll is done and succeeds (but no verifying)
> or
> C. no enroll or verifying is done, it goes straight to manageble
>
> 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.
>
> available
> ------------
> In our state machinery, a node goes from enroll -> verifying -> manageable
> -> cleaning -> available. For available to be initial state, does it mean
> that
> A. whatever is needed for enroll, verifying, cleaning is done and succeeds
> (under the hood)
> or
> B. whatever is needed for enroll is done and succeeds (but no verifying or
> cleaning)
> or
> ??
>
> active
> --------
> 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
> A. whatever is needed for enroll, verifying, cleaning, deploying is done and
> succeeds (under the hood)
> or
> B. whatever is needed for enroll is done and succeeds (but no verifying or
> cleaning)
> or
> 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?
>

What I'm more concerned about allowing the enroll a node in any stable
state is that it's going to be a big change in our API. We have PATCH
as a mechanism of updating a resource partially because we have
read-only attributes (driver_internal_info, *_updated_at, etc...) in
the API that are internal and should not be updated by the user. Some
states might depend on them i.e a node in ACTIVE state might have
indicators in the driver_internal_info field.

Another thing it's really cross resource, a node in ACTIVE state will
depend on a certain port which it was used to be deployed (and other
things about registering that port in Neutron with the right DHCP
information, so if one is PXE booting after ACTIVE the node won't get
stuck with a boot error. (Also we need to create the right TFTP (or
TFTP + HTTP for iPXE) environment for that node.

Anyway, I don't want to get much deeper, I think we should all be open
to hear what will be proposed with a fresh mind.

Cheers,
Lucas