On Thu, Mar 17, 2011 at 11:23:32AM -0700, David Lutterkort wrote:
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.
I have a feeling we're closer to agreement than we think here.
Here are some things I'm pretty sure are true:
1. Right now, in the absence of our config server, we need to be able to inject a relatively large amount of data into the instance (I mean, a few kb, anyway) for configuration to work right. My guess is that over time we want to continue supporting that "we don't have a config server" case, although I'm not at all sure about that.
2. Once we do have a config server, we really only need two very small pieces of information: a UUID for the guest, and a DNS name or IP address for the config server. (We'll leave out the possibility of ipv6 zeroconf or DNS SRV records for now just to keep things under control.) All the other config for an instance will come from the config server. (Again somebody correct me if I'm wrong here.)
It seems to me this probably argues for two different things in the API: an "inject a userblob" API that is generic, maybe the max userblob size varies from cloud to cloud but the semantics are identical, and we support it everywhere; and an "inject an identity" API that we support whenever the underlying cloud supports it. I don't see a major problem with Conductor understanding the difference between these two cases, since it seems to me we'll need to know whether the cloud we're talking to has a config server present and therefore which kind of data we need to inject, *anyway*. (JRD correct me if I'm wrong here.) So at a glance I'm not sure I have a problem with having these two different APIs, since they seem to serve two different purposes.
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.
Certainly Conductor wants to use DC API to talk to Falcon, I don't think that's at issue. I guess the question is how much additional logic do we need to add (if any) for the Falcon cloud case that isn't already in the DC API. Frankly, I'm going to let you guys figure that one out -- my standpoint is that I want to have to do as little work as possible to support this.
I hope this hasn't muddied the waters more. Let me know,
Take care, --H