Open Stack

On Sep 15, 2014 8:20 AM, "James Slagle" <james.slagle at gmail.com> wrote:
>
> 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.
>

When I say the ironic API is admin only, I'm speaking to the required
permissions for accessing it. One must be authenticated with keystone
with the "admin" privilege. Borrowing from the ops guide:

" An administrative super user, which has full permissions across all
projects and should be used with great care."

I'm not sure how TripleO is dividing operator and admin in the
undercloud - so I just want to be clear on what you mean when you say
"may not be the undercloud admin". Simply put, to use Ironic in the
undercloud, you must have "admin" privileges in the undercloud -- or
you need to disable Ironic's auth entirely.

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

Heat has a mission. It's not just a hammer with which to parse
json/yaml/etc into a for loop and throw text at an API. From the wiki:

"... to create a human- and machine-accessible service for managing
the entire lifecycle of infrastructure and applications within
OpenStack clouds."

The resources ironic exposes are not "within OpenStack clouds." They
are _underneath_ the cloud. Actually, they're underneath the
undercloud.

Configuring a node in Ironic is akin to configuring the SAN from which
Cinder provisions volumes. That is clearly a thing which an operator
needs to do -- but are you suggesting that, if my SAN has a REST API,
I should use Heat to configure it?

This is the crux of my objection. I would be surprised if your answer
is "yes, heat should be used to configure my SAN". If you're wondering
why I used that example, it's because folks already asked me if they
can use Ironic to deploy their SAN's management software, perform
firmware upgrades on it, and so on. (I said "no, not today" but it's
an interesting scope discussion for Ironic).

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

As others have said already, based on discussions during the Juno
cycle, discovery has not landed, and most of us agree that it is out
of scope.

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

These steps are desirable not just the first time a node is added to
ironic, but often subsequently, either between every deployment, or
when the operator changes the role/function that hardware fulfills, or
if the hardware components are replaced.

I suspect the workflow to apply the necessary changes, handle errors,
etc, across a fleet of servers in varying states of use (by tenants)
and disuse (eg, have some failed hardware components) is going to be
much too complex for Heat's declarative model.

-Devananda