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

[Serge Hallyn]

Quoting Stéphane Graber (stgraber at ubuntu.com):
> On 04/10/2013 06:49 AM, Serge Hallyn wrote:
> > Quoting S.Çağlar Onur (caglar at 10ur.org):
> >> Hi Serge,
> >>
> >> On Tue, Apr 9, 2013 at 4:47 PM, Serge Hallyn <serge.hallyn at ubuntu.com>wrote:
> >>
> >>> All right you made me finally take a closer look at the monitor code
> >>> (which I'd been avoiding).  It's much simpler than I'd imagined.  So
> >>> here are the challenges:
> >>>
> >>> 1. lxc-monitor should be able to watch 'all containers' (at least under
> >>> a given lxcpath).  That is actually the strong reason to object to your
> >>> patch.
> >>>
> >>
> >> Ah, that makes sense.
> >>
> >>
> >>> 2. we don't want to force any long-running daemon to run as the monitor.
> >>> 3. we want to allow multiple containers to send state change info
> >>> to multiple simulataneous lxc-monitor and lxc-wait listeners.
> >>>
> >>> Now I can think of some whacky solutions, but are there any simple ones
> >>> I'm overlooking?
> >>
> >>
> >> I'm not sure what is your whacky solution but if I'm not missing something
> >> this sounds like multicast :) I'm sorry for my ignorance but did multicast
> >> unix sockets patch set find its way into upstream kernel?
> > 
> > It looks to be a tough sell to the networking maintainer :)
> > 
> > http://lkml.org/lkml/2012/2/28/369
> > 
> > -serge
> 
> So my basic plan for the monitor was to allow multiple connections to
> the socket with the easiest way of doing that being to use
> multithreading, spawning a thread for each connection.

Who's doing this thread-spawning?  You're assuming a long-running
daemon, which violates #2 above.  If we're ok with that, then that
definately simplifies things.

> There are other ways to deal with non-blocking reads on multiple sockets
> (basically an infinite loop of accept/read without threading) which we
> may want to look into if we want to avoid threading.
> 
> 
> Now, having that information broadcast may have its value, but I think
> in LXC itself, we should probably stick to unicast and leave
> broadcasting this to an external piece of software which would use our
> API to monitor all the containers and provide some kind of bridge to DBus.
> The current obvious "multi-casty" thing on the Linux desktop is DBus and
> while we could theoretically use it as a replacement for our current
> unix socket, I don't really think we want to bring it as a dependency
> for LXC.
> 
> 
> -- 
> Stéphane Graber
> Ubuntu developer
> http://www.ubuntu.com
> 



> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel