On Mon, 2018-05-21 at 10:38 +0200, Jakub Hrozek wrote:
> On 18 May 2018, at 21:50, Simo Sorce <simo(a)redhat.com>
> Sorry Pavel,
> but I need to ask, why a new bus instead of somthing like varlink ?
Do you think there is an advantage with varlink over D-Bus as long as
we use a private style of communication and use either varlink or D-
Bus more or less as a marshalling mechanism?
Only if we have to start from scratch or make significant changes, I
wouldn't embark on replacing the tool just for the sake of replacing.
> > > Now, I'm integrating it into SSSD. The work is quite difficult since
> > > touches all parts of SSSD and the changes are usually interconnected but
> > > slowly moving towards the goal .
> > >
> > > At this moment, I'm trying to take "miminum changes" paths
so the code can
> > > be built and function with sbus2, however to take full advantage of it,
> > > will take further improvements (that will not be very difficult).
> > >
> > > There is one big change that I would like to take though, that needs to
> > > discussed. It is about how we currently handle sbus connections.
> > >
> > > In current state, monitor and each backend creates a private sbus server.
> > > The current implementation of a private sbus server is not a message bus,
> > > only serves as an address to create point to point nameless connection.
> > > each client must maintain several connections:
> > > - each responder is connected to monitor and to all backends
> > > - each backend is connected to monitor
> > > - we have monitor + number of backends private servers
> > > - each private server maintains about 10 active connections
> > >
> > > This has several disadvantages - there are many connections, we cannot
> > > broadcast signals, if a process wants to talk to other process it needs
> > > connect to its server and maintain the connection. Since responders do
> > > currently provider a server, they cannot talk between each other.
> This design has a key advantage, a single process going down does not
> affect all other processes communication. How do you recover if the
> "switch-board" goes down during message processing with sbus ?
FWIW, this is a worry I also expressed to Pavel on the phone the other day.
> > > sbus2 implements proper private message bus. So it can work in the same
> > > as session or system bus. It is a server that maintains the connections,
> > > keep tracks of their names and then routes messages from one connection
> > > another.
> > >
> > > My idea is to have only one sbus server managed by monitor.
> This conflict wth the idea of getting rid of the monitor process, do
> not know if this is currently still pursued but it was brought up over
> and over many times that we might want to use systemd as the "monitor"
> and let socket activation deal with the rest.
It’s something we’ve been talking about but never got around to
implementing. Additionally, there are users who are running sssd in
a container for better or worse and I’m not sure we systemd in a
container is something used or stable outside some test builds..
So .. we do not know :-)
Sr. Principal Software Engineer
Red Hat, Inc