On 16/09/14 13:56, Devananda van der Veen wrote:
On Mon, Sep 15, 2014 at 9:00 AM, Steven Hardy <sha...@redhat.com> 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
My apologies if the following sounds snarky -- but I think there are a
few misconceptions that need to be cleared up about how and when one
might use Ironic. I also disagree that 1..5 looks like application
orchestration. Step 4 is a workflow, which I'll go into in a bit, but
this doesn't look at all like describing or launching an application
+1 (Although step 3 does sound to me like something that matches Heat's
Step 1 is just parse a text file.
Step 2 should be a prerequisite to doing -anything- with Ironic. Those
images need to be built and loaded in Glance, and the image UUID(s)
need to be set on each Node in Ironic (or on the Nova flavor, if going
that route) after enrollment. Sure, Heat can express this
declaratively (ironic.node.driver_info must contain key:deploy_kernel
with value:NNNN), but are you suggesting that Heat build the images,
or just take the UUIDs as input?
Step 3 is, again, just parse a text file
I'm going to make an assumption here [*], because I think step 4 is
misleading. You shouldn't "boot a node" using Ironic -- you do that
through Nova. And you _dont_ get to specify which node you're booting.
You ask Nova to provision an _instance_ on a _flavor_ and it picks an
available node from the pool of nodes that match the request.
I think your assumption is incorrect. Steve is well aware that
provisioning a bare-metal Ironic server is done through the Nova API.
What he's suggesting here is that the nodes would be booted - not
Nova-booted, but booted in the sense of having power physically applied
- while in maintenance mode in order to do autodiscovery of their
capabilities, which is presumably hard to do automatically when they're
turned off. He's also suggesting that Heat could drive this process,
which I happen to disagree with because it is a workflow not an end
state. However the main takeaway here is that you guys are talking
completely past one another, and have been for some time.
Step 5 is a prerequisite for step 4 -- you can't boot a node that is
in maintenance mode, and if the node is not in maintenance mode, Nova
exposes it to clients. That is in fact how you'd boot it in step 4.
[*] I'm assuming you are not planning to re-implement the Nova
"ironic" driver in Heat. Booting a node with Ironic is not just a
matter of making one or two API calls. It's a declarative
transformation involving multiple changes in Ironic's API, and
presumably also some calls to Neutron if you want network access
to/from your node, and polling the resource to see when its state
converges on the requested state. Actually that sounds like exactly
the sort of thing that Heat could drive. But all this is already
implemented in Nova.
OpenStack-dev mailing list
OpenStack-dev mailing list