[Freeipa-users] changing the default for changelog trimmimg

Petr Spacek pspacek at redhat.com
Fri Jul 3 13:00:13 UTC 2015


On 3.7.2015 14:45, Ludwig Krispenz wrote:
> 
> On 07/03/2015 02:28 PM, Petr Spacek wrote:
>> On 3.7.2015 14:21, thierry bordaz wrote:
>>> On 07/03/2015 02:03 PM, Petr Spacek wrote:
>>>> On 3.7.2015 11:45, thierry bordaz wrote:
>>>>> On 06/30/2015 03:54 PM, Ludwig Krispenz wrote:
>>>>>> Hi,
>>>>>>
>>>>>> 389-ds allows to configure the max size of the replication changelog either
>>>>>> by setting a maximum record number or a maximum age of changes.
>>>>>> freeIPA does not use this setting. In the context of ticket
>>>>>> https://fedorahosted.org/freeipa/ticket/5086 we are discussing to change
>>>>>> the
>>>>>> default to
>>>>>> enable changelog trimming.
>>>>>>
>>>>>> Does anyone already use changlog trimming or is there a  scenario where you
>>>>>> rely on all changes being available ?
>>>>>>
>>>>>> Thanks for your feedback,
>>>>>> Ludwig
>>>>>>
>>>>> Hello,
>>>>>
>>>>>      I think it is reasonable to set nsds5ReplicaPurgeDelay and
>>>>>      nsslapd-changelogmaxage to similar value.
>>>>>
>>>>>      When a replica (master or consumer) is down for some time and is
>>>>>      restarted, both attribute express the ability to get the replica in
>>>>>      sync with the rest of the topology.
>>>>>      It can work (and likely will) if
>>>>>      nsds5ReplicaPurgeDelay<nsslapd-changelogmaxage but there are always
>>>>>      corner cases that can lead to problem (like entries that diverge).
>>>>>
>>>>>      Currently purgedelay=7days (default) and changelogmaxage is infinite
>>>>>      and changing purgedelay=infinite impacts the size of the entries.
>>>> I wonder if these values could/should be controlled by topology plugin. Does
>>>> it make sense to have different values on different replicas?
>>>>
>>> Purgedelay can be different on each replica but it makes sense that the value
>>> is the same on all replicas. It is used to remove too old csn and so how far
>>> in the past the replication can decide which value is more recent than an
>>> other one. With different values of purge delay, a replica can decide to keep
>>> one value and an other replica can decide the opposite.
>>> Currently purgedelay is identical on all replicas (default value).
>> I understand that technically it is possible so the question is more like
>> 'does it even make sense'?
> no, it doesn't make sense. At least I can't imagine a scenario, where it does
>> Do we want to support it?
> what exactly do you mean by this, you always can as a last method edit the
> dse.ldif, even if you can catch all online mods by a plugin like the topo plugin.
> do we offer an easy way to configure and modify it, I think: no
> does one loose support if changing the default, no

I'm asking if we as FreeIPA project are willing to support such configuration
or not. It is our decision - and we can make statements about supportability
and add technical measures to prevent *accidental* changes.

-- 
Petr^2 Spacek




More information about the Freeipa-users mailing list