[Freeipa-devel] limiting SyncRepl's scope

[Jakub Hrozek]

On Wed, Dec 16, 2015 at 09:26:11AM +0100, Sumit Bose wrote:
> On Wed, Dec 16, 2015 at 08:49:04AM +0100, Petr Spacek wrote:
> > On 15.12.2015 19:10, Christian Heimes wrote:
> > > Hi,
> > > 
> > > in ticket https://fedorahosted.org/freeipa/ticket/5538 Ludwig has
> > > suggested to exclude Dogtag's o=ipaca tree from the changelog. Sometimes
> > > vault-archive fails because of a failed write to the Retro Changelog.
> > > The RetroCL was enabled in https://fedorahosted.org/freeipa/ticket/3967
> > > for the bind-dyndb-ldap plugin. Otherwise it is not needed under normal
> > > circumstances because 389 doesn't use SyncRepl for replication. In #3967
> > > Nathan has expressed his concerns for possible performance issues, too.
> > > 
> > > Petr, Ludwig,
> > > would it makes sense to restrict RetroCL to cn=dns,$SUFFIX rather than
> > > excluding o=ipaca? The plugin supports both includes and exclude,
> > > http://directory.fedoraproject.org/docs/389ds/design/retrocl-scoping.html.
> > 
> > >From IPA DNS perspective it is okay to limit SyncRepl to cn=dns,$SUFFIX.
> > 
> > One other thing to consider is theoretical use of SyncRepl for future versions
> > of slapi-nis, Alexander can tell you more about it.
> > 
> > In any case, if we decide to limit scope where SyncRepl is applicable, I would
> > like to see checks in SyncRepl plugin which will ensure that error
> > UNWILLING_TO_PERFORM is returned when somebody attempts to use SyncRepl in a
> > 'wrong' scope.
> > 
> 
> There are discussions about using SyncRepl in SSSD as well which would
> include users, groups, sudo and HBAC rules, trusted domains, ... But
> afaik no work in the direction has been started yet, so it might be ok
> to limit the scope for now and add it when there are patches for SSSD
> which really try to use it.

The more I was looking into the sssd performance problems in the last
couple of weeks, the more I think we don't actually need syncrepl on the
clients, maybe only in server mode sssd..

Even the refreshOnly mode has cost associated (IIRC Ludwig told me the
server has to check all changelog entries since the cookie) and I think
on the clients we could improve performance with looking up entries as we
do now, checking if the modifyTimestamp has changed and if not, avoid the
cache write as we discussed over the phone the other day.

For server mode sssd, syncrepl might be interesting, yes. But as you said, so
far I only looked into issues that would also benefit the pure client case.