Please review design proposal for tickets 47986 and 48976

[Ludwig Krispenz]

This is the initial proposal, thanks for your feedback

http://www.port389.org/docs/389ds/design/delay-accepting-updates-after-init....

[Noriko Hosoi]

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....

Please help me understanding the design...

I'm having a bit hard time to figure out the relationship/dependency 
among these 3 config parameters.

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.  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?  For instance, if -auto is "on", when an online init is 
executed on the master, the scenario is automatically kicked in?

Thanks,
--noriko

||

[Ludwig Krispenz]

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....
>
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Ludwig Krispenz]

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....
> >
> > 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 [e-mail]
> > To unsubscribe send an email [e-mail]
>
> -- 
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

[William Brown]

On Fri, 2016-10-07 at 17:58 +0200, 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

I think the accept-updates state is better managed in a separate
pre-operation plugin which is able to distinguish internal vs external
updates. I'm actually writing something like this at the moment in my
free time which could work here.

...
> > > nsslapd-replica-accept-updates-state: on/off
> > > nsslapd-replica-accept-updates-delay: -1/0/n
> > > nsslapd-replica-accept-updates-auto: on/off

This configuration is really confusing. I can see how it's meant to
work, but I don't like it.

Again, I'm really against adding more configuration options. We should
do "the right thing by default, always". Admins are lazy and aren't
going to fine tune their replication for fun.

My vote is scrap these two configuration options, and just make it
"auto" behaviour.

[thierry bordaz]

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-init....
> > >
> > > 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 [e-mail]
> > > To unsubscribe send an email [e-mail]
> >
> > -- 
> > 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 [e-mail]
> > To unsubscribe send an email [e-mail]
>
> -- 
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Ludwig Krispenz]

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-init....
> > > >
> > > > 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 [e-mail]
> > > > To unsubscribe send an email [e-mail]
> > >
> > > -- 
> > > 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 [e-mail]
> > > To unsubscribe send an email [e-mail]
> >
> > -- 
> > 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 [e-mail]
> > To unsubscribe send an email [e-mail]
>
> 389-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]