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 to 389-devel-leave(a)lists.fedoraproject.org