Open Stack

On Mon, Sep 15, 2014 at 7:44 AM, Steven Hardy <shardy at redhat.com> wrote:
> 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.

After a cursory reading of the references, it seems there's a couple of issues:
- are the features to move hardware to a "ready-state" even going to
be in Ironic proper, whether that means in ironic at all or just in
contrib.
- assuming some of the features are there, should Heat have any Ironic
resources given that Ironic's API is admin-only.

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

I think it makes a lot of sense to use Heat to do the bulk
registration of nodes via Ironic. I understand the argument that the
Ironic API should be "admin-only" a little bit for the non-TripleO
case, but for TripleO, we only have admins interfacing with the
Undercloud. The user of a TripleO undercloud is the deployer/operator
and in some scenarios this may not be the undercloud admin. So,
talking about TripleO, I don't really buy that the Ironic API is
admin-only.

Therefore, why not have some declarative Heat resources for things
like Ironic nodes, that the deployer can make use of in a Heat
template to do bulk node registration?

The alternative listed in the spec:

"Don’t implement the resources and rely on scripts which directly
interact with the Ironic API, prior to any orchestration via Heat."

would just be a bit silly IMO. That goes against one of the main
drivers of TripleO, which is to use OpenStack wherever possible. Why
go off and write some other thing that is going to parse a
json/yaml/csv of nodes and orchestrate a bunch of Ironic api calls?
Why would it be ok for that other thing to use Ironic's "admin-only"
API yet claim it's not ok for Heat on the undercloud to do so?


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

My opinion is that if the features are in Ironic, they should be
exposed via Heat resources for orchestration. If the TripleO case is
too much of a one-off (which I don't really think it is), then sure,
keep it all in contrib so that no one gets confused about why the
resources are there.

-- 
-- James Slagle
--