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