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.
> 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
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
> 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.
> 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.
> I prefer the "supporting" mode (if we find a better name), as long as no
> admin interferes the info in the shared tree and cn=config will be
> identical as they are set in a normal deployment, so no harm is done,
> but they are replicated and the full information is available on every
Full topology information you mean here, right ?
Simo Sorce * Red Hat, Inc * New York
Freeipa-devel mailing list