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.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
