Open Stack

On Wed, 2014-01-29 at 20:03 -0500, Zane Bitter 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
> >> 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.)

I'm not touching on that at all, either. 

I'm just pointing out that the "task" resource object currently being
worked on in the Glance API is not really a resource at all -- the
resource is an Image. Whether or not the Image resource changes state
during certain events (like image upload or translation) does not mean
that state change should be represented as a resource in the API.

Best,
-jay