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 _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
