On Wed, Jan 20, 2010 at 2:09 PM, David Lutterkort lutter@redhat.com wrote:
I think you're disappointed with the messenger ;)
Oh no - not disappointed ;) just more thinking as how *I* would like to use it - as Roman pointed out in his blog, to make it useful this minimal injection was needed. But what was interesting was that with that minimal injection, he was able to do something useful. I would think if someone is happily sticking with rackspace they would use the nice rackspace api directly (should they want features that it offers over deltacloud) - the few clouds I know about have something that would map to this or else come very close without a lot of work at all.
I agree that portability is far more than this, but this inches us a bit closer (keep in mind I am thinking portability of applications - not so much in taking an entire image and moving it intact). ie avoiding any overt lock-in to a specific cloud in terms of my application.
Perhaps file injection (as Brian mentioned in a separate thread) is one of the "inbetween" things that really should be in a version of the API, but perhaps with additional features on top of that discoverable. The discoverable stuff would need to make sure it covers enough of what other clouds offer, otherwise people may as well go direct.
To stick with file/user-data injection: today, only EC2 and Rackspace give you some capability to do that as far as I can tell. EC2 does the user-data thing that you can access via HTTP inside the image, Rackspace lets you write up to five small files anywhere in the file system. The only way in which we could make that difference disappear is to simulate EC2's user-data on Rackspace by putting user-data into a fixed file in the filesystem - that's unsatisfactory for people who want to use deltacloud only for Rackspace, since we've removed a feature.
Both mechanisms are reasonable, and I would hope that other cloud providers will follow one of these instead of inventing yet another one. That in itself means that you can port applications from one cloud to another as long as they support the same injection mechanism - deltacloud will take care of minor differences of how exactly you inject that data. If you don't want to bother with discovery, ensure in some other way that all the clouds you're targeting support the features you need, e.g. restrict yourself to a subset of drivers.
To get portability to a wider range of clouds, an application needs to be aware to some extent of the differences between clouds - there's no way we can pretend in deltacloud that GoGrid (or most other clouds) support any sort of data injection. To help those, more complex, applications, deltacloud should tell them about features that only some of the drivers support.
So, I see adding capabilities metadata and allowing discovery not as a restriction of what people can do, but a help for people who want or need to do more complicated things.
David