On 04/10/2013 08:15 PM, Serge Hallyn wrote: > Quoting Christian Seiler (christ...@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
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
