[openstack-dev] [ironic][heat][mistral][magnum] Manage Ironic resource in Orchestration.

Pavlo Shchelokovskyy pshchelokovskyy at mirantis.com
Mon Dec 12 11:48:22 UTC 2016


Hi all,

On Mon, Dec 12, 2016 at 1:17 PM, Steven Hardy <shardy at redhat.com> wrote:

> 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.
>

Not sure it it would be relevant, but Ironic now has support for
notifications sent over RPC bus (and there is an ongoing implementation for
SearchLight plugin in this regard). In particular, notifications can be
enabled on node changing its provisioning state, so any system that can
listen to those notifications can be configured/taught to react on node
reaching the ACTIVE state.


>
> >    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
>
> __________________________________________________________________________
> 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
>

Cheers,
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161212/2b076121/attachment.html>


More information about the OpenStack-dev mailing list