On Wed, Mar 16, 2011 at 07:47:40PM -0400, John R. Dunning wrote:
From: David Lutterkort <lutter@redhat.com> Date: Wed, 16 Mar 2011 11:12:22 -0700 On Wed, 2011-03-16 at 08:54 -0400, John R. Dunning wrote: > From: David Lutterkort <lutter@redhat.com> > Date: Tue, 15 Mar 2011 17:05:24 -0700 > > On Tue, 2011-03-15 at 14:46 -0400, Chris Lalancette wrote: > > On 03/15/11 - 01:35:53PM, Ian Main wrote: > > > > 3. We believe we can arrange to pass a small snippet of config data > > > > in at launch time, to point a booting instance at some source of > > > > further config. > > > > > > Kernel boot params, yes. > > > > Note that this won't work. In general, you can't add kernel boot params to > > a guest, because we don't direct-boot the kernel. We boot the emulated BIOS, > > which calls grub, which calls the kernel. > > > > Luckily there is a workaround. We can stuff some data into the SMBIOS tables > > during launch time, and use that as our injection mechanism instead. > > There's also door #3, which would be hugely preferrable from an API POV: > using kpartx^W libguestfs to directly inject files into the image. This > is the approach Rackspace takes; IOW, we wouldn't introduce yet another > paradigm of how to inject user data into an instance. > > Do you mean pry open the image a few ms before launch, frob something > in it, then launch? Yes, since we already have to have a copy (or a COW snapshot) before launching the instance, we'd just use virt-edit[1] to modify files in the instance's image. In reality, this would boil down to using the libguestfs Ruby bindings [2] This should not be much of an effort to implement. > That's ok if you've got a backend which doesn't do, for instance, COW, > while running multiple instances from a single image file. We absolutely have to either have COW or a per-instance copy of the image.
Sure.
> Besides, if we're arguing from the API point of view, who cares what > the underlying implementation is? One of the main points of having an > API in the first place is to allow for hiding wacky implementation > details, especially when there are multiple implementations involved. 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. Thats not to say that we might not opt to allow the full glory of individual backends to show through in backend-specific ways, but we ought to be able to define a subset which we present in a common fashion.
This particular point is off topic for this conversation. If you'd like to discuss further, let's take it offline.
I agree with John here -- unless there's a really good reason to expose to the user the details of how we do userdata injection, why wouldn't we want to hide them? What benefit does exposing the details grant to the user?
> SMBIOS is fine for internal instrumentation (e.g., where to report IP > address), but not for generic user data. > > I think all that's being proposed to go in smbios is a 32-bit dingus > (ip address of server) and a somewhat longer dingus for instance UID. > If we need 128 bits for that, it's 160 bits total. Is that acceptable > to stash in smbios at boot time? 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, and if we decide further that in that standalone mode we want to make available facilities which aren't relevant when it's used as part of CE, that will be a worthy discussion to have. For now, I think we should focus on the simple cases which alloc CE to do what it needs.
Here's to focusing on the simple case!
--Hugh