Open Stack

On Mon, Sep 15, 2014 at 12:59 PM, Clint Byrum <clint at fewbar.com> wrote:
> Excerpts from James Slagle's message of 2014-09-15 08:15:21 -0700:
>> On Mon, Sep 15, 2014 at 7:44 AM, Steven Hardy <shardy at redhat.com> wrote:
>> > 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.
>>
>
> And I think if this is a common thing that Ironic users need to do,
> then Ironic should do it, not Heat.

I would think Heat would be well suited for the case where you want to
orchestrate a workflow on top of existing Ironic API's for managing
the infrastructure lifecycle, of which attaining ready state is one
such use case.

It's a fair point that if these things are common enough to all users
that they should just be done in Ironic. To what extent such an API in
Ironic would just end up orchestrating other Ironic API's the same way
Heat might do it would be hard to tell. It seems like that's the added
complexity in my view vs. a set of simple Heat resources and taking
advantage of all the orchestration that Heat already offers.

I know this use case isn't just about enrolling nodes (apologies if I
implied that in my earlier response). That was just one such use that
jumped out at me in which it might be nice to use Heat. I think about
how os-cloud-config registers nodes today. It has to create the node,
then create the port (2 separate calls). And, it also needs the
ability to update registered nodes[1]. This logic is going to end up
living in os-cloud-config.

And perhaps the answer is "no", but it seems to me Heat could do this
sort of thing easier already if it had the resources defined to do so.
It'd be neat to have a yaml file of all your defined nodes, and use
stack-create to register them in Ironic. When you need to add some new
ones, update the yaml, and then stack-update.

[1] http://lists.openstack.org/pipermail/openstack-dev/2014-August/043782.html
(thread crossed into Sept)

-- 
-- James Slagle
--