Open Stack

On Mon, Dec 12, 2016 at 04:18:59PM +0800, Rico Lin wrote:
>    Think about bare metal (ironic) deployment, we can do directly ironic
>    call, or use nova to deploy.
>    Right now I have a spec about implemented Ironic resources [1] in Heat.
>    Including Chassis, Port and some state setting feature for Node
>    (including node-set-xxx). In heat team discussion, we tend to not
>    implement Node deployment feature.
>
>    If we counting Ironic action into three parts:
>    1. Create the node in the ironic DB
>    2. Do a series of steps to get the node in a state where it's ready for
>    deployment (this may include introspection via ironic-inspector, or just
>    changing the state)
>    3. Select a node and drive a workflow that deploys an image on it.

Yes, I think a heat resource is a good fit for (1), but less so for (2) and
(3), because these are really workflows.  I started looking into ways of
automating those workflows via mistral here (WIP, needs more work):

https://review.openstack.org/#/c/313048/

So what I would like is to finish that deployment workflow, then have some
way to drive it via heat, e.g:

resources:
  the_node:
    type: OS::Ironic::Node
    properties:
      <node details required by ironic>

  node_deploy_workflow:
    type: OS::Mistral::Workflow
    properties:
      input:
        node: {get_resource: the_node}
        tasks:
          <definition of tasks to deploy node>

There are two missing pieces (other than fixing the workflow example I
referenced above):

1. The Ironic node heat resource
2. Some way to actually execute the mistral workflow during the stack create

I think (1) is pretty simple, I wrote some resources that do that
previously ref https://review.openstack.org/#/c/104223/ - but that effort
stalled because at that time we didn't have a good answer to how we'd drive
the deployment workflow (IMO we do now, it's mistral).

The missing part for (2) is that currently OS::Mistral::Workflow expects a
signal to actually create a workflow execution and run the workflow.  I
think we need some other option (a boolean that says run once when we
create the resource perhaps?) to make it more convenient to drive a one-off
workflow during a stack create/update in a synchronous way.

>    We can do in Heat is to use Nova on (3) and hope someone already
>    handles on (1) and (2). If we consider (1) and (2) also part of Heat
>    resources, we can actually make entire management done in heat template.

While we could implement the workflow directly in the heat resources, IMO
it'd be nice to consider mistral instead, unless there are objections to
making that a dependency when solving this problem.

I actually think Nova is much less interesting for many Ironic use-cases,
e.g for TripleO all we use nova for is to schedule to groups of nodes using
a very simple filter.  It'd be very nice to remove any dependency on Nova
and just drive deployments with explicit node placement directly via Ironic
(either via Heat, or Heat->Mistral, or just Mistral depending on your
preferences).

>    The use case in my head was ironic+magnum case:
>    Ironic resource handles state we need, then through magnum resource, nova
>    will deploy that baremetal node and config it as part of COE.
>    The open question is if heat really implemented such feature, who will
>    benefit from it and how are they going to use it? We certainly don't want
>    to implement something that no one will use it or not even think it's a
>    good idea.

I think TripleO definitely would benefit from this work too - I'd just like
to see it done in a way which makes depending on Nova optional (it's a
major overhead, and for some baremetal deployment use-cases, it's not
providing much value).

>    And which projects might be a good fit if it's not a good idea to do in
>    heat?
>    We can also think about the possibility of implement it with putting it in
>    Nova resource in heat if it's a baremetal case, Heat+Mistral, or just
>    Mistral will do.

My preference would be Heat+Mistral as discussed above, but open to other
ideas.

I don't think conflating any of this with the Nova resource is a good idea
- if we decide to implement the workflow directly in heat as an alternative
to depending on Mistral it should probably be a new resource, perhaps
implemented with a properties schema that makes overridding the normal nova
server resource easy.

I still think Heat+Mistral provides a cleaner solution tho, so I'd like to
see that further explored before committing to an internal reimplementation
of such workflow.

Thanks for reviving this topic - I'm certainly interested in helping move
this forward and/or discussing further.

Steve