On Tue, 2014-06-03 at 15:47 +0200, Ludwig Krispenz wrote: > On 06/03/2014 02:53 PM, Simo Sorce wrote: > > On Tue, 2014-06-03 at 14:15 +0200, Ludwig Krispenz wrote: > >> Hi Simo, > >> > >> just for clarification. The plan is to move the repl config into the > >> shared tree for the main database and eventually for others like > >> o=ipaca. Should the topology info live in cn=etc for all databases or > >> each in the database it configures ? > >> If the main database is always replicated I think all topology info > >> should be concentrated in cn=etc. > > This is actually a good question, I think we want to keep it in the main > > database, but to be forward looking, we should set the basedn of the > > configuration (per topology) in the topology plugin configuration entry, > > this way if it turns out we should move it in their own dbs we can just > > do it. > yes, this can be handle in the topology plugin configuration, we need to > define which databases should be controlled and where the root for the > replicated topology information is. > I assume we want only one plugin instance. > > > > The other issue is the list of masters though. I do not want to move > > them in the topology tree (breaks compatibility) nor duplicate those > > entries if possible, but we may need to do it or also configure where > > the "nodes" are stored. > Agreed. What about non-masters, in the ticket there was also discussion > about read only replicas - to be delayed ?
TBD, from the pov of the plugin we care only about Nodes and links, but yeah dealing with R/O replicas will mean the plugin should understand such servers need a segment that sends data to them but do not need a segment that carries data out. Working on the topology consistency checker will be fun :-) Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel