On Wed, 2014-06-04 at 18:04 +0200, thierry bordaz wrote: > On 06/04/2014 05:41 PM, 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. > I like the idea that the node can add itself and the connection to the > topology tree. > But this requires that the node database is already initialized (have > the same replicageneration than the others nodes). > If it is not initialized, it could be done by any masters. But if it is > automatic, there is a risk that several masters will want to initialize it. > > In addition if the new node has a different replicageneration, how does > the new node know that it should wait to be initialized rather than > initialize the others.
Yeah see my follow-up, I think a flag would be better, this way import is done only once and never more. If a node is already initialized then the topology plugin will always wipe away and reconfigure agreements in cn=config from the topology tree and never backwards. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
