[openstack-dev] [tripleo][heat][ironic] Heat Ironic resources and "ready state" orchestration
Devananda van der Veen
devananda.vdv at gmail.com
Tue Sep 16 19:52:37 UTC 2014
Now that I've replied to individual emails, let me try to summarize my
thoughts on why Heat feels like the wrong tool for the task that I
think you're trying to accomplish. This discussion has been really
helpful for me in understanding why that is, and I think, at a really
high level, it is because I do not believe that a description of a
cloud application should contain any direct references to Ironic's
resource classes. Let me explain why.
Heat is a declarative engine, where its inputs are: the stated desired
state of a complex system, and the actual state of that system. The
actual state might be that no resources have been created yet (so Heat
should create them) or a set of existing resources (which Heat
previously created) that need to be mutated to achieve the desired
state. This maps reasonably well onto the orchestration of launching
an application within a cloud. Great.
Nova, Cinder, Neutron, etc, provide APIs to control resources within a
cloud (instances, storage volumes, IPs, etc). These are the building
blocks of an application that Heat will use.
Ironic provides a declarative API to model physical configuration of
hardware. This doesn't actually correlate to an application in the
cloud, though Nova understands how to map its resource types (flavors
and instances) onto an available pool of hardware. It is conceivable
that Ironic might, at some point in the future, also be able to manage
switch and storage hardware configuration, firmware updates, etc, as
well. We don't today, but more than one interested developer/vendor
has already approached us asking about that.
By adding Ironic resource templates to Heat, you are, in my view,
moving it beyond the ken of "cloud application orchestration" and into
"inventory management", which is a space that has a lot of additional
complexity, and a lot of existing players.
For what it's worth, I acknowledge that this is possible (and I
apologize if my prior arguments made it seem like I didn't understand
that). But just because it can be done, doesn't mean it /should/ be
done.
Thanks for bearing with me as I organized my thoughts on this,
Devananda
More information about the OpenStack-dev
mailing list