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