On Wed, 2011-03-16 at 19:47 -0400, John R. Dunning wrote:
Not quite - the two existing ways of userdata injection, EC2-style via a special webserver, and RAX-style by scribbling in the FS, can not really be exposed in the same way in the Deltacloud API. So for API-level user-data injection, I'd rather stick with one of those two approaches than introduce yet a third method.
Well, ok, but please recall that the reason why we're going to the trouble to build a stateful layer in front of the falcon backend is precisely to avoid showing vagaries of backends through. Instead, we are opting to present a uniform model, and hide the details behind the api.
If we can't do that similarly for userdata, or a subset of it, I submit that we're doing something wrong.
We can try and produce a LCD version of these facilities, though there's a very high danger that that forces us to break API compatibility: imagine we wallpapered over the data injection differences between EC2 and RAX by saying 'you can give us a userblob to inject into the instance, up to 10kB; in EC2 it will be posted at 169.254.169.254, for RAX it will wind up in /var/lib/userblob' Now we add Falcon's SMBIOS based data injection - we immediately broke API because we can't inject 10kB of data anymore into any cloud that supports the 'userblob'.
In any event, these simplifications are really application policy.
This particular point is off topic for this conversation. If you'd like to discuss further, let's take it offline.
Sure - but it's an important point in making sure Deltacloud remains a versatile API.
That's fine for the bits of data that Falcon needs for its IP-sniffing purposes. It's probably not enough for what we'd offer users through the API.
Again, the purpose of the falcon backend is to serve the needs of cloud engine. It's much more interesting, to me, and I suspect to Hugh's group, to make that work first. If, after that, we decide that there's value in making it available separate from cloud engine, and if we decide further that it makes sense to present DC as the front end for it
Isn't DC the abstraction that CE uses to talk to backend clouds ? Why would CE talk to Falcon with anything else than DC ? At the very least, it would force CE to do a lot more special casing than what we discussed above for user-data.
David