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'
- in-sync->backend
- 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-init.html
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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
--
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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
--
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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
--
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
|
