hmm, well, it could make sense to move the runscript option into the Template.
We are currently guarding all changes to the template based on discoverable, or statically coded features of the cloud. With the runscript inside the template, we can check support on the image so that the API call doesn't fall flat on its face in an unsupported scenario ;)
anyway, this is more fodder for the jclouds-dev group than deltacloud. I'll leave you to it.
thanks for the feedback, David. Cheers, -Adrian
On Thu, Jan 21, 2010 at 3:46 PM, David Lutterkort lutter@redhat.com wrote:
On Fri, 2010-01-22 at 09:33 +1100, Michael Neale wrote:
On Fri, Jan 22, 2010 at 5:28 AM, David Lutterkort lutter@redhat.com wrote:
Yes, exactly - it has to be optional, since not all clouds support it. If/when that feature settles down in clouds we can think about a new rev of the API that offers it for all clouds - but that's some way out.
Adrian Cole pointed out the jclouds way of doing this:
http://code.google.com/p/jclouds/wiki/ComputeGuide#Adding_a_post-boot_script
This is a single file injection of a script. If not supported, fallback to SSH will be required so it can do it.
There are many ways how you can simulate one with the other, _if_ you are willing to instrument your images, e.g. through ssh. If the image is not instrumented, your whole API call falls flat on its face.
Deltacloud is a general-purpose cloud API, and as such can't assume that images are instrumented in any particular way. The situation is very different with jclouds which can make all kinds of assumptions about what's in the image.
David
deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel