On 15/09/14 12:00, Steven Hardy wrote:
For example, today, I've been looking at the steps required for driving


Driving this process looks a lot like application orchestration:

1. Take some input (IPMI credentials and MAC addresses)
2. Maybe build an image and ramdisk(could drop credentials in)
3. Interact with the Ironic API to register nodes in maintenance mode
4. Boot the nodes, monitor state, wait for a signal back containing some
    data obtained during discovery (same as WaitConditions or
    SoftwareDeployment resources in Heat..)
5. Shutdown the nodes and mark them ready for use by nova

At some point near the end of this sequence, you could optionally insert
the "ready state" workflow described in the spec.

So I guess my question then becomes, regardless of ready state, what is
expected to drive the steps above if it's not Heat?

Maybe you're not explaining it the way you intended to, because I was more or less on board until I read this, which doesn't sound like Heat's domain at all. It sounds like a workflow, of the kind that could in future be handled by something like Mistral.

Only step 3 sounds like a job for Heat (i.e. involves a declarative representation of some underlying resources). I think it certainly makes sense to use Heat for that if it can have some meaningful input into the lifecycle (i.e. you can usefully update to add and remove nodes, and unregister them all on delete). If not then it's hard to see what value Heat adds over and above a for-loop.

For the record, IMO the fact that the Ironic API is operator-facing should *not* be an obstacle here. We have an established policy for how to handle such APIs - write the plugins, maintain them in /contrib - and this proposal is entirely consistent with that.


OpenStack-dev mailing list

Reply via email to