On Thu, 2010-01-21 at 15:54 +1100, Michael Neale wrote:
Right, so perhaps I was getting things confused in my mind. So what you are suggesting is that some file injection feature is part of the api - but in an optional section. And the api would provide a way to query what in the optional section is available?
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.
What would be nice would be to pick either the Rackspace or the EC2 way of injection, and make that the "normal" way - and emulate it if really needed (in the driver if necessary) for the other (I think that would be possible to do the EC2 way in Rackspace without too much trouble). In time cloud providers would possibly provide it anyway.
The question is: which way to do it will "win" ? If we emulate user-data with file injection on Rack, and every other cloud starts offering file injection[1], we'd have restricted the API unnecessarily.
If its discovering 2 different ways to do file injection, I don't think I would like that (unless 1 type is a super set of the other type - if you follow what I mean).
I think, for now, we should stick more closely to what different clouds offer, simply because we can't tell yet what will become the prevalent mechanism. Client-side, it's a fairly simple check - assuming 'api' holds a DOM for the toplevel api entry point, your client would do something like
if xpath(api, "/api/link[rel='instances']/feature[@name='user-data']) params.add("user-data", user_data) else if xpath(api, "/api/link[rel='instances']/feature[@name='user-files']) file = { :path => "/var/lib/misc/user-data.txt", :data => user_data } params.add("user-files", file) else lose end create_instance(params)
You could probably add another 10 lines or so to do some sanity checking, but it's really not a crazy amount of code.
David
[1] I don't see that happening, since file injection is _much_ more problematic than EC2's user-data. Just bear with me for the sake of argument.