Open Stack

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
>> output.
>>
>> 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.
>
> https://wiki.openstack.org/wiki/Glance-tasks-import#Initial_Import_Request

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

cheers,
Zane.