[Freeipa-devel] Move replication topology to the shared tree

[Simo Sorce]

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