What I am having trouble with for this is that it's not clear to me how
to express that in a cross-cloud way.
For clouds that do not support file injection (e.g., EC2), we'd need to
make sure that the image is built in a certain way; should we carry
additional image metadata to tell us which images have been prepped with
a 'file injector' for EC2 ? Or should we assume that file injection will
eventually be available on any cloud ? That heavily influences how we
would express file injection on the API level.
David
And this is the pointy end of things with deltacloud. Say I was
building a *tool* which allowed me to work across clouds, then in that
case I would do what I needed to plug the gaps for clouds which did
not support what I considered an essential service. I guess in device
driver terms it is "emulated"? (or perhaps they use more colorful
language for that kind of hacking ;).
However, is deltacloud aiming to be, in the end, a common API
specification with a supporting reference implementation and some core
drivers? or is it an integration layer which specifies and API and
also how to emulate missing features for a cloud to participate in it?
If the latter, then the "drivers" provide low level common access to
the clouds, and then the upper layers emulate missing features on top
of that if needed. If the former, then it means we have different
levels of API 'compliance' etc...
Optimistically speaking, the excellent participation in deltacloud
means that it is likely that "missing" features won't be missing for
long in various cloud providers - but does that mean in the meantime
we want to emulate things by whatever means necessary?