Thanks,
I may have missed it, but your suggestion about configuring and
behaviour sounds good. I will update my doc.
Regards,
Ludwig
On 10/12/2016 05:19 PM, thierry bordaz wrote:
Hello,
I would think of two options
* If admin decides to switch to backend, it should not be prevented
and the backend moves to 'backend'
* periodic (hourly) checking (IMHO not configurable and always run),
checking being the same mechanism as 'auto'
o in-sync->backend
o not-in-sync it keeps referral-on-update
I think that the delay option is not necessary. If periodic checking
fails to move to referral-on-update, it will log a msg saying which
consumer knows higher csn and it will be the admin task to make sure
to push those updates.
For internal operation, I do not think to any simple solution. The
mechanism in your design is a real progress from what is now. Let's
wait for CU cases to see if we need to also address internal ops.
regards
thierry
On 10/07/2016 05:58 PM, Ludwig Krispenz wrote:
> there is a problem not yet covered in the proposal: setting the
> backend to "referral-on-update" until the topology is in sync
> prevents to ealry client updates, but what to do about internal
> updates, eg passwordpolicy attributes.
>
> I have a wild idea, but maybe someone has a suggestion on how to
> handle this
>
> thanks,
> Ludwig
>
> On 10/05/2016 05:51 PM, Ludwig Krispenz wrote:
>>
>> On 09/30/2016 02:15 AM, Noriko Hosoi wrote:
>>> Hi Ludwig,
>>>
>>> On 09/29/2016 05:43 AM, Ludwig Krispenz wrote:
>>>> This is the initial proposal, thanks for your feedback
>>>>
>>>>
http://www.port389.org/docs/389ds/design/delay-accepting-updates-after-in...
>>>>
>>>>
>>> Please help me understanding the design...
>>>
>>> I'm having a bit hard time to figure out the
>>> relationship/dependency among these 3 config parameters.
>>>
>> sorry if I was not clear enough, I will update the doc, but let me
>> try to explain here
>>>
>>> nsslapd-replica-accept-updates-state: on/off
>>> nsslapd-replica-accept-updates-delay: -1/0/n
>>> nsslapd-replica-accept-updates-auto: on/off
>>>
>>> Are they independent or dependent? Do they take any combinations
>>> -- 2 * 3 * 2 == 12.
>>>
>> no. the primary parameter is: nsslapd-replica-accept-updates-state
>> If it is off, the other determine when it should be set to on again
>> (without an explicite change by an admin).
>> if it is on, the other two will not be used
>>
>> independent of auto on/off the "delay" defines if(>=0) the state
>> will be reset to on and when
>>
>> the "auto" param determines if the server should in the defined
>> "delay" it should try to detect if it is in sync and switch to
"on"
>> earlier.
>>
>>> There are 12 different behaviors? (assuming n for -delay is one
>>> case :)
>>>
>>> What is your recommendation to the customers? I mean, what is the
>>> default setting?
>>>
>> that is a good question, there is the option to choose the default
>> by what is "my" recommendation (auto: on, delay: n) or what is
>> backward compatible (no change in default behaviour: auto off, delay: 0)
>>>
>>> For instance, if -auto is "on", when an online init is executed
>>> on the master, the scenario is automatically kicked in?
>>>
>>> Thanks,
>>> --noriko
>>>
>>>
>>>
>>>
>>>
>>> ||
>>>
>>>
>>> _______________________________________________
>>> 389-devel mailing list --389-devel(a)lists.fedoraproject.org
>>> To unsubscribe send an email to389-devel-leave(a)lists.fedoraproject.org
>>
>> --
>> Red Hat
GmbH,http://www.de.redhat.com/, Registered seat: Grasbrunn,
>> Commercial register: Amtsgericht Muenchen, HRB 153243,
>> Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill,
Eric Shander
>>
>>
>> _______________________________________________
>> 389-devel mailing list --389-devel(a)lists.fedoraproject.org
>> To unsubscribe send an email to389-devel-leave(a)lists.fedoraproject.org
>
> --
> Red Hat
GmbH,http://www.de.redhat.com/, Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric
Shander
>
>
> _______________________________________________
> 389-devel mailing list --389-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to389-devel-leave(a)lists.fedoraproject.org
_______________________________________________
389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric
Shander