[lxc-devel] [PATCH] Use container specific domain socket name

[Stéphane Graber]

On 04/10/2013 08:15 PM, Serge Hallyn wrote:
> Quoting Christian Seiler (christian at iwakd.de):
>> Hi there,
>>
>>> Let's say I do
>>>
>>> 	sudo lxc-monitor -n r1 -n r2
>>>
>>> and now do
>>>
>>> 	sudo lxc-start -n r1
>>>
>>> How do we know to send the 'started' event to the lxc-monitor, since
>>> there was not yet a lxc-start daemon running?
>>
>> Just to throw my 2¢ in there - why not use DBus for that? It seems to me
>> that DBus has already solved all of the problems that occur here. And
>> one wouldn't need to care about multi-threading, because one only talks
>> to the DBus daemon itself.
> 
> Right, so we'd be using dbus's long-running daemon, so that we don't
> need our own.  (which I clarify to point out that they didn't "solve
> this problem" :)
> 
> I'd actually be ok with this, but Stéphane mentioned he doesn't want
> dbus to become a dependency.  It seems to me dbus is pretty much
> ubiquitous anyway, but I trust he has use cases where it would be an
> undue burden.
> 
> -serge

Right, one problem with requiring DBus is for the Android port of LXC on
which access to a DBus system-bus isn't guaranteed.

I also suspect some people who've been using LXC on restricted/embedded
platform wouldn't be too happy with us using DBus for our IPC.


I however don't think I'd mind us connecting to the DBus system bus and
exposing our control API on DBus so long as we don't hard depend on it.

I think it's definitely valuable to be able to monitor and control
containers over DBus and that it'll open a whole set of new
possibilities and fits rather well with our user namespace work (where
we'd simply use the session bus), the problem really is about making
sure lxc-stop/lxc-wait/lxc-... don't depend on a system bus to be setup.

One way to do that is to use something like Upstart did with libnih-dbus
where we actually have our own builtin DBus server. If we detect a
system bus, we connect to it and expose everything to it, if we don't,
we listen on a hard-coded guessable abstract socket but still use the
DBus protocol.
The advantage of this is that you don't hard-depend on a system bus,
systems that don't have it simply connect directly to the abstract
socket (similar to our existing monitor socket) but still use the exact
same protocol and path as they'd use against the system bus.


One trick however is that DBus is usually designed in a way that a
single process (daemon) that's either spawned at boot time or
DBus-activated owns a specific DBus address. In the case of LXC, this
isn't the case. We'd basically need a separate DBus address for every
container as we don't actually have a single daemon owning a single
address on the bus. (As far as I know two processes can't own different
"paths" on the same "address").



Yet another proposal I'm just putting out there would be the following:
 - Keep our monitor protocol mostly as it's, just make it more
comprehensive, fix known bugs, ...
 - Create an OPTIONAL long-lasting management daemon
 - Have LXC poke that daemon on a pre-defined abstract socket when
initializing. If it's there, then either send the container's socket
address to that daemon or have lxc-start send status updates back to the
daemon every time something changes.
 - Have that daemon own net.sourceforge.lxc (or whatever name we
register) and expose the DBus API on the system bus.
 - Update the LXC API to always try using DBus by default and only
reverting to direct unix sockets if DBus isn't available.

This should give us the following benefits:
 - Works on system without DBus (with our existing problems)
 - Offers a "standard" DBus interface to people who want to use it
 - Transparently integrates with our existing code as an optional
feature that just makes things more reliable (at the cost of a bit of
memory/cpu).

Obviously this comes at the cost of having to code and maintain said
daemon and updating the API to handle the DBus/socket fallback.

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20130410/b3ab319a/attachment.pgp>