Open Stack

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?

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.

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