Open Stack

On Wed, Aug 19, 2015 at 09:48:29AM +0100, Lucas Alvares Gomes wrote:
> 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.
> 

+1, there are tons of dragons here. Now that we're to the point where
our state machine is well-defined with a single entrypoint, I think
adding any entrypoints needs to be well thought out. We should be able
to make assumptions about what we can do from a given state, and if we
are going to allow folks to define other entrypoints, those assumptions
need to be satisfied.

I'm somewhat open to adding entrypoints, but I'd like to see specs
first.

// jim

> Cheers,
> Lucas
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev