On 08/19/2015 02:05 AM, Ruby Loo wrote:
On 17 August 2015 at 20:20, Robert Collins
<robe...@robertcollins.net <mailto:robe...@robertcollins.net>>
wrote:
On 11 August 2015 at 06:13, Ruby Loo <rlooya...@gmail.com
<mailto:rlooya...@gmail.com>> wrote:
> Hi, sorry for the delay. I vote no. I understand the rationale of
trying to
> do things so that we don't break our users but that's what the
versioning is
> meant for and more importantly -- I think adding the ENROLL state
is fairly
> important wrt the lifecycle of a node. I don't particularly want
to hide
> that and/or let folks opt out of it in the long term.
>
> From a reviewer point-of-view, my concern is me trying to
remember all the
> possible permutations/states etc that are possible to make sure
that new
> code doesn't break existing behavior. I haven't thought out
whether adding
> this new API would make that worse or not, but then, I don't
really want to
> have to think about it. So KISS as much as we can! :)
I'm a little surprised by this, to be honest.
Here's why: allowing the initial state to be chosen from
ENROLL/AVAILABLE from the latest version of the API is
precisely as
complex as allowing two versions of the API {old, new} where old
creates nodes in AVAILABLE and new creates nodes in ENROLL.
The only
difference I can see is that eventually someday if {old}
stops being
supported, then and only then we can go through the code and
clean
things up.
It seems to me that the costs to us of supporting graceful
transitions
for users here are:
1) A new version NEWVER of the API that supports node state
being one
of {not supplied, AVAILABLE, ENROLL}, on creation, defaulting to
AVAILABLE when not supplied.
2) Supporting the initial state of AVAILABLE indefinitely
rather than
just until we *delete* version 1.10.
3) CD deployments that had rolled forward to 1.11 will need
to add the
state parameter to their scripts to move forward to NEWVER.
4) Don't default the client to the veresions between 1.10
and NEWVER
versions at any point.
That seems like a very small price to pay on our side, and the
benefits for users are that they can opt into the new
functionality
when they are ready.
-Rob
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 :)
Again...
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).
And I want node to be created in INSPECTING state directly. I don't care
it's a transient state, I just want it :) Oh, and can I please skip
MANAGEABLE? I need the following flow INSPECTING->AVAILABLE.
Now seriously: to what degree are we going to allow people to break our
state machine? Or alternatively, are we going to allow steps to happen
automatically? I'm in favor of this idea actually, maybe someone feels
like writing a spec?
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
?
B. No more breaking changes please.
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
A sounds nice, but that's now how our state machine currently works.
Being able to skip states is really an interesting feature, but it
requires somewhat broader discussion. And then yes, you should allow me
to just straight into INSPECTING in this case :)
If it's not implied, then my vote is:
D. don't do it
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.
And I get bug reports like "inspector does not work". Sigh...
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?
--ruby
[0] http://docs.openstack.org/developer/ironic/dev/states.html
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
