[openstack-dev] [Heat] How to model resources in Heat
mark.washenberger at markwash.net
Thu Jan 30 20:41:40 UTC 2014
On Wed, Jan 29, 2014 at 5:03 PM, Zane Bitter <zbitter at redhat.com> wrote:
> On 29/01/14 19:40, Jay Pipes wrote:
>> On Wed, 2014-01-29 at 18:55 -0500, Zane Bitter wrote:
>>> I've noticed a few code reviews for new Heat resource types -
>>> particularly Neutron resource types - where folks are struggling to find
>>> the appropriate way to model the underlying API in Heat. This is a
>>> really hard problem, and is often non-obvious even to Heat experts, so
>>> here are a few tips that might help.
>>> Resources are nouns, they model Things. Ideally Things that have UUIDs.
>>> The main reason to have a resource is so you can reference its UUID (or
>>> some attribute) and pass it to another resource or to the user via an
>>> If two resources _have_ to be used together, they're really only one
>>> resource. Don't split them up - especially if the one whose UUID other
>>> resources depend on is the first to be created but not the only one
>>> actually required by the resource depending on it.
>> Right. The above is precisely why I raised concerns about the "image
>> import/upload tasks" work ongoing in Glance.
> At least the dependencies there would be in the right order:
> ImportTask <- Image <- Server
> but if you were to model this in Heat, there should just be an Image
> resource that does the importing internally.
> (I'm not touching the question of whether Heat should have a Glance Image
> resource at all, which I'm deeply ambivalent about.)
Maybe I'm just missing the use case, but it seems like modeling anything
Glance-y in Heat doesn't quite make sense. If at all, the dependency would
run the other way (model heat-things in glance, just as we presently model
nova-things in glance). So I think we're in agreement.
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev