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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
