On Wed, 2014-06-04 at 11:41 -0400, Simo Sorce wrote: > On Wed, 2014-06-04 at 13:46 +0200, Ludwig Krispenz wrote: > > On 06/04/2014 10:43 AM, thierry bordaz wrote: > > > > > >> > > >> So my proposal would contain the following components > > >> > > >> 1] Store replication configuration in the shared tree in a > > >> combination of server and connection view (think we need both) and > > >> map replication configuration to these entries. I would prefer a > > >> direct mapping (with a subset of the cn=config attributes and > > >> required additions) > > > > > > About adding a new server in the replication topology. > > > If it was initialized, it may register itself into the shared tree and > > > then join the topology. If it was not initialized, it can be > > > initialized online by one of the master. Will it be triggered with an > > > update to the shared tree ? > > > > I think this has to be decided, I proposed some kind of bootstrapping: > > If the topology plugin is enabled and started it would check if there is > > already info on the connections for this server and if not create/update > > the entry in the shared tree, this could also happen if a new server is > > added. > > You mean updating the shared tree from information about replication > agreements found in cn=config ? > I can see how this would be useful in migration from previous server > versions, but I fear would cause issues if you remove a connection when > one of the 2 servers is down. > When you bring the server up it would try to re-create a connection that > was deleted by the admin. It's a catch-22 which is why I want the shared > tree to be authoritative but not the cn=config tree. > > > But Simo wanted to have the info in the shared tree indepndent of what > > was already configured. > > It's not much about being independent, it's about what is authoritative > and what is not. > > > One problem with the automatic approach is what should be done if the > > config differs on the already deployed servers > > That's just one of many problems. > I think cn=config entries should be read an injected in the shared > topology only once at upgrade time, but not anymore after. > Maybe this calls for adding nodes to the topology tree, if the topology > plugin starts and the server is not in the topology tree, then it > sources the local configuration, then adds itself and the connections to > the topology tree. > If the node is already in the topology tree this step is always skipped. > > Or something similar (could be just a flag in cn=masters objects).
Replying to myself, a flag on the cn=masters servers is probably better, because otherwise connection objects would reference "missing" nodes (servers that have not already been upgraded) or they would cause the creation of missing node (for integrity) and that would cause those servers to not be able to import their agreements. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
