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.
Or something similar (could be just a flag in cn=masters objects).
makes sense ?
Simo.
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
