On Thu, 2014-06-05 at 11:27 +0200, Ludwig Krispenz wrote:
On 06/04/2014 06:04 PM, thierry bordaz wrote:
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.
I would not give the plugin the power to reinitialize a database on
another server and I also would not put the responsibility to do it to
the plugin. Initializing a server is an administrative task done at
specific steps during deployment or in error conditions and most time
has to be scheduled and often on-line initialization is not the
preferred method.
Agree.
The plugin could still be used to trigger online initializations if the
nsds5replicarefresh attribute is part of the information in the shared
tree, it can be modified, the plugin on the targeted server will detect
the change, update the replication agreement object and start the
initialization (but this should probably still be allowed to be done
directly).
Nope, leave re-initialization to the plumbing. The topology plugin deals
only with topology, it should not be involved with re-initializations,
save for not going crazy and trying to remove agreements "during" a
re-initialization.
The question for me was more how the configuration information in the
shared tree is initialized (not the full shared tree).
We do agree that the info in the shared tree should be authoritative.
Yep.
To
synchronize the info in the shared tree and cn=config I see two modes:
"passive" mode: the sync is only from the shared tree to cn=config, it
is the responsibility of an admin/tool to initialize the config in the
shared tree
This is my preferred, although leaves the problem open for migration, we
need a way to properly prime the topology so that it doesn't wipe out
current agreements before they are imported.
"supporting" mode: if the plugin starts, it checks if the info in the
shared tree exists, if not it initializes the topology info in the
shared tree and then only reacts to changes in the shared tree.
I would like some more details about what you have in mind here,
depending on the fine points I might agree this is desirable to solve
the migration problem.
