On Thu, 2014-06-05 at 16:46 +0200, Ludwig Krispenz wrote: > On 06/05/2014 03:14 PM, Ludwig Krispenz wrote: > > > > On 06/05/2014 02:45 PM, Simo Sorce wrote: > >> 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 will write it down for a few different scenarios. > looks like this could get ugly, if the topology info initialization > would happen on several masters at the same time, they would create the > same entries (at least the config root container) and we could get > replication conflicts :-(
This is exactly why I said I do not want the plugin to create the topology tree itself :-) It should only import agreements that are not yet there. There is still potential conflict, the topology plugin will have to handle them, by intercepting replication writes to the topology tree and smartly merging/fencing IMO. > we need to be careful on the process, I have an idea how it could work, > but need to think a bit more about it I am all ears. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
