Open Stack

On 15/09/14 12:00, Steven Hardy wrote:
> For example, today, I've been looking at the steps required for driving
> autodiscovery:
>
> https://etherpad.openstack.org/p/Ironic-PoCDiscovery-Juno
>
> 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.

cheers,
Zane.