Open Stack

Excerpts from Steven Hardy's message of 2014-09-15 04:44:24 -0700:
> All,
> 
> Starting this thread as a follow-up to a strongly negative reaction by the
> Ironic PTL to my patches[1] adding initial Heat->Ironic integration, and
> subsequent very detailed justification and discussion of why they may be
> useful in this spec[2].
> 
> Back in Atlanta, I had some discussions with folks interesting in making
> "ready state"[3] preparation of bare-metal resources possible when
> deploying bare-metal nodes via TripleO/Heat/Ironic.
> 
> The initial assumption is that there is some discovery step (either
> automatic or static generation of a manifest of nodes), that can be input
> to either Ironic or Heat.
> 
> Following discovery, but before an undercloud deploying OpenStack onto the
> nodes, there are a few steps which may be desired, to get the hardware into
> a state where it's ready and fully optimized for the subsequent deployment:
> 
> - Updating and aligning firmware to meet requirements of qualification or
>   site policy
> - Optimization of BIOS configuration to match workloads the node is
>   expected to run
> - Management of machine-local storage, e.g configuring local RAID for
>   optimal resilience or performance.
> 
> Interfaces to Ironic are landing (or have landed)[4][5][6] which make many
> of these steps possible, but there's no easy way to either encapsulate the
> (currently mostly vendor specific) data associated with each step, or to
> coordinate sequencing of the steps.
> 

First, Ironic is hidden under Nova as far as TripleO is concerned. So
mucking with the servers underneath Nova during deployment is a difficult
proposition. Would I look up the Ironic node ID of the nova server,
and then optimize it for the workload after the workload arrived? Why
wouldn't I just do that optimization before the deployment?

> What is required is some tool to take a text definition of the required
> configuration, turn it into a correctly sequenced series of API calls to
> Ironic, expose any data associated with those API calls, and declare
> success or failure on completion.  This is what Heat does.
> 

I'd rather see Ironic define or adopt a narrow scope document format
that it can consume for bulk loading. Heat is extremely generic, and thus
carries a ton of complexity for what is probably doable with a CSV file.

> So the idea is to create some basic (contrib, disabled by default) Ironic
> heat resources, then explore the idea of orchestrating ready-state
> configuration via Heat.
> 
> Given that Devananda and I have been banging heads over this for some time
> now, I'd like to get broader feedback of the idea, my interpretation of
> "ready state" applied to the tripleo undercloud, and any alternative
> implementation ideas.
> 

I think there may be value in being able to tie Ironic calls to other
OpenStack API calls. I'm dubious that this is an important idea, but
I think if somebody wants to step forward with their use case for it,
then the resources might make sense. However, I realy don't see the
_enrollment_ phase as capturing any value that isn't entirely offset by
added complexity.