On Sun, 2010-01-17 at 09:14 +1100, Michael Neale wrote:
FWIW, rackspace offers injection by passing a file path and a Base64
encoding of file data (only up to 10kb though). I know others offer
similar things (such as rimu, or will shortly). So at least on the
rackspace side, the driver could accomodate it by injecting it into
the server create request "message".
If there is a minimal single file injection we can agree on (is a
single file enough?) - then I think this really should be in
deltacloud, as it makes it workable for many many cases. I think its
reasonable to expect cloud providers to have this (as I think they all
pretty much do) without having to emulate it with a post-startup
script (which would be what people do now I guess).
From an API POV, we should support both, and let people discover what
mechanism the backend cloud supports. Anything else, for example,
simulating EC2's user-data mechanism on rackspace by injecting a fixed
file will lead to a lowest-common denominator API.
What I am thinking is that we indicate such variations in the toplevel
api.xml. For example, instead of just saying
<link href="http://localhost:3000/api/instances"
rel="instances"/>
for EC2 we'd say
<link href="http://localhost:3000/api/instances"
rel="instances">
<operation name="create">
<user-data>
<maxsize unit="kB">16</maxsize>
</user-data>
</operation>
</link>
and for Rack we'd say
<link href="http://localhost:3000/api/instances"
rel="instances">
<operation name="create">
<user-files max="5">
<maxsize="10" unit="kB">10</maxsize>
<path-length unit="byte">255</path-length>
</user-files>
</operation>
</link>
That way, applications can discover which mechanism for file injection
the cloud supports, and act accordingly.
David