Open Stack

On Mon, Sep 15, 2014 at 11:15:21AM -0400, James Slagle 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.

Intially at least, it sounds like much of what "ready-state" entails would
be via Ironic vendor-specific extensions.

But that's not necessaily an insurmountable problem IMO - encapsulating the
vendor-specific stuff inside some provider resource templates would
actually enable easier substitution of different vendors stuff based on
deployment time choices (user input or data from autodiscovery).

> - assuming some of the features are there, should Heat have any Ironic
> resources given that Ironic's API is admin-only.

Yes, we have some admin-only resources already, but they're restricted to
contrib, as generally we'd rather keep the main tree (default enabled)
resources accessible to all "normal" users.

So, given that all actors in the undercloud will be admins, as noted in the
spec, I don't think this is a problem given that the primary use-case for
this stuff is TripleO.

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

\o/

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

Yeah this mirrors my thoughts, I suppose the alternative is somewhat
flippant, but I was trying to illustrate that exposing the Ironic API via
Heat provides some interesting opportunities for reuse of existing Heat
capabilities.

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

At some point near the end of this sequence, you could optionally insert
the "ready state" workflow described in the spec.

So I guess my question then becomes, regardless of ready state, what is
expected to drive the steps above if it's not Heat?

I'm not really clear what the plan is but it certainly seems like it'd be
a win from a TripleO perspective if the exiting tooling (e.g Heat) could be
reused?

Steve