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).

makes sense ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to