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

[Simo Sorce]

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.

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

Full topology information you mean here, right ?

Simo.

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