Open Stack

On 16/09/14 13:56, Devananda van der Veen wrote:
> On Mon, Sep 15, 2014 at 9:00 AM, Steven Hardy <shardy at redhat.com> 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
>>
>
> 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
> to me.

+1 (Although step 3 does sound to me like something that matches Heat's 
scope.)

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

cheers,
Zane.

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