Open Stack

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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>