[Freeipa-devel] [PATCH] move replication topology to shared tree

[Simo Sorce]

On Tue, 14 Oct 2014 15:10:21 +0200
Ludwig Krispenz <lkrispen at redhat.com> wrote:

> 
> On 10/14/2014 02:39 PM, Simo Sorce wrote:
> > On Tue, 14 Oct 2014 10:12:24 +0200
> > Ludwig Krispenz <lkrispen at redhat.com> wrote:
> >
> >> ok for me, I was just straightforward reading cn=config to get
> >> cn=config info, but I like the idea to do it via rootdse.
> >> we have to expose the suffix(es) controlled by the topology plugin
> >> and the entry point for the shared config info.
> > I was thinking in rootDSE we'd expose just if the feature was
> > available. For IPA that would suffice, for generic 389ds then you'd
> > have top look at configuration to find DNs.
> > I am not sure exposing DNs directly from rootDSE is necessary.
> I had two cases in mind, which I think would apply to IPA.
> 
> - in an IPA installation in many scenarios you two suffixes: 
> "dc=.....,dc=com" and "o=ipaca". It could be possible to use the
> plugin to manage "dc=.." only. Or do you say it's all or nothing ?
> If there is a choice, client utilities need to be able to find out
> which suffix is managed.
> 
> - even in an ipa installation nobody prevents an admin to add other 
> backends to the directory server for other usage, so you might have
> "dc=example,dc=com"
> "dc=test,dc=com"
> "dc=anotherbackend,dc=com"
> "o=ipaca"
> 
> in which suffix is the shared topology data ? should we query each 
> suffix to see if something useful is returned ?

Well, at least for the IPA case I do not think we want to have multiple
topology trees, even for multiple topologies, rather we want to have
the ability to mark the same segment as used for X,Y,Z topologies (1-1
between topology and database).

This will make it much simpler to handle simple configurations in which
you simply want the CA and IPA topologies to be identical, by having a
default that says new segments cover both topologies in the UI.

Of course we also need to be able eventually to separate those, but
again I see it done better by 'tagging' the single object with the
topology it belongs to, than having completely different trees by
default. (Having separate trees supported is also a desirable feature
for the generic plugin so one does not exclude the other).

Simo.

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