[openstack-dev] [Heat] Long-term, how do we make heat image/flavor name agnostic?
adrian.otto at rackspace.com
Fri Jul 19 15:06:26 UTC 2013
On Jul 18, 2013, at 5:18 PM, Gabriel Hurley <Gabriel.Hurley at nebula.com> wrote:
> Generally spot-on with what Adrian said, but I have one question from that email:
>> Mappings is one of the high level concepts in CFN that I think can be
>> completely eliminated with auto-discovery.
> What do you mean by this? What kind of autodiscovery, and where? I'm all for eliminating mappings someday if possible, but I haven't heard this proposal before. Enlighten me?
The concept works by using a set of declared requirements, which are matched by the model interpreter in the orchestration system to resources/services that provide them. For example, one template may declare that it needs "linux", and the resource/service Nova can provide that.
This is something that has been worked on quite a bit in the open standards community. Namely, both the TOSCA and CAMP spec drafts have these concepts to some extent.
AFAIK, Heat does not yet have a sophisticated model interpreter, so this concept is something that we could iterate towards over time. What I am sure exists today is that resources have specific names that you can use to order any of the OpenStack services. You can declare you want a particular resource name when authoring your template. This does work within a single cloud, but it does not eliminate the need for mappings in order to make anything portable, because there is no guarantee that the resource name will exist innaother cloud, or that it will work the same.
There is more to this concept than what fits in a couple of paragraphs, but this should give you a general idea.
More information about the OpenStack-dev