On 05/20/2016 02:54 PM, Steven Hardy wrote:
Hi Dmitry,
Thanks for the detailed write-up, some comments below:
On Thu, May 19, 2016 at 03:31:36PM +0200, Dmitry Tantsur wrote:
<snip>
what do you propose?
--------------------
I would like the new TripleO mistral workflows to start following the ironic
state machine closer. Imagine the following workflows:
1. register: take JSON, create nodes in "manageable" state. I do believe we
can automate the enroll->manageable transition, as it serves the purpose of
validation (and discovery, but lets put it aside).
2. provide: take a list of nodes or all "managable" nodes and move them to
"available". By using this workflow an operator will make a *conscious*
decision to add some nodes to the cloud.
3. introspect: take a list of "managable" (!!!) nodes or all "manageable"
nodes and move them through introspection. This is an optional step between
"register" and "provide".
4. set_node_state: a helper workflow to move nodes between states. The
"provide" workflow is essentially set_node_state with verb=provide, but is
separate due to its high importance in the node lifecycle.
5. configure: given a couple of parameters (deploy image, local boot flag,
etc), update given or all "manageable" nodes with them.
Essentially the only addition here is the "provide" action which I hope you
already realize should be an explicit step.
what about tripleoclient
------------------------
Of course we want to keep backward compatibility. The existing commands
openstack baremetal import
openstack baremetal configure boot
openstack baremetal introspection bulk start
will use some combinations of workflows above and will be deprecated.
The new commands (also avoiding hijacking into the bare metal namespaces)
will be provided strictly matching the workflows (especially in terms of the
state machine):
openstack overcloud node import
openstack overcloud node configure
openstack overcloud node introspect
openstack overcloud node provide
So, provided we maintain backwards compatibility this sounds OK, but one
question - is there any alternative approach that might solve this problem
more generally, e.g not only for TripleO?
I was thinking about that.
We could move the import command to ironicclient, but it won't support
TripleO format and additions then. It's still a good thing to have, I'll
talk about it upstream.
As to introspect and provide, the only thing which is different from
ironic analogs is that ironic commands don't act on "all nodes in XXX
state", and I don't think we ever will.
Given that we're likely to implement these workflows in mistral, it
probably does make sense to switch to a TripleO specific namespace, but I
can't help wondering if we're solving a general problem in a TripleO
specific way - e.g isn't this something any user adding nodes from an
inventory, introspecting them and finally making them available for
deployment going to need?
Also, and it may be too late to fix this, "openstack overcloud node" is
kinda strange, because we're importing nodes on the undercloud, which could
in theory be used for any purpose, not only overcloud deployments.
I agree but keeping our stuff in ironic's namespace leads to even more
confusion and even potential conflicts (e.g. we can't introduce
"baremetal import", cause tripleo reserved it).
We've already done arguably the wrong thing with e.g openstack overcloud image
upload (which, actually, uploads images to the undercloud), but I wanted to
point out that we're maintaining that inconsistency with your proposed
interface (which may be the least-bad option I suppose).
Thanks,
Steve
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
