[jira] [Commented] (ZOOKEEPER-1989) backward compatibility of zoo.cfg

[Hongchao Deng (JIRA)]

    [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14075114#comment-14075114
 ] 

Hongchao Deng commented on ZOOKEEPER-1989:
------------------------------------------

hey [~shralex].

Here's what I think the minimal change we can do:
1. On fresh bootup, we still keep _clientPort_ in _zoo.cfg_ in old config.
2. let's assume clientPort is mandatory in reconfig. When a client do a 
reconfig command, it will delete the _clientPort_ in zoo.cfg.

This guarantee both consistency as you mentioned and backward compatibility. 
Let me give two examples

h3. Problem Context
Let's assume we have server A and B and we ignore the middle two ports and role.

{noformat}
A, zoo.cfg:
  ...
  clientPort=CP_A
  server.A=ip_A
  server.B=ip_B
{noformat}

{noformat}
B, zoo.cfg:
  ...
  clientPort=CP_B
  server.A=ip_A
  server.B=ip_B
{noformat}

After deploying 3.5, it boots up with

{noformat}
A, zoo.cfg:
  ...
  clientPort=CP_A
zoo.cfg.dynamic:
  server.A=ip_A
  server.B=ip_B
  version=xxx
{noformat}

{noformat}
B, zoo.cfg:
  ...
  clientPort=CP_B
zoo.cfg.dynamic:
  server.A=ip_A
  server.B=ip_B
  version=xxx
{noformat}

h3. Change client port on A
Let’s change A’s client port to CP_A2. After reconfig, it should become:

{noformat}
A, zoo.cfg:
  ...
zoo.cfg.dynamic:
  server.A=ip_A; CP_A2
  server.B=ip_B
  version=xxx
{noformat}

{noformat}
B, zoo.cfg:
  ...
  clientPort=CP_B
zoo.cfg.dynamic:
  server.A=ip_A; CP_A2
  server.B=ip_B
  version=xxx
{noformat}

What’s happening here is that every server still know its client port. But on 
reconfig, it would make dynamic files consistent across quorum.

h3. Add a new server C
{noformat}
C, zoo.cfg:
  ...
zoo.cfg.dynamic:
  server.A=ip_A
  server.B=ip_B
  server.C=ip_C; CP_C
{noformat}

After reconfig, A and B will 

{noformat}
A, zoo.cfg:
  ...
  clientPort=CP_A
zoo.cfg.dynamic:
  server.A=ip_A
  server.B=ip_B
  server.C=ip_C; CP_C
  version=xxx
{noformat}

{noformat}
B, zoo.cfg:
  ...
  clientPort=CP_B
zoo.cfg.dynamic:
  server.A=ip_A
  server.B=ip_B
  server.C=ip_C; CP_C
  version=xxx
{noformat}


> backward compatibility of zoo.cfg
> ---------------------------------
>
>                 Key: ZOOKEEPER-1989
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1989
>             Project: ZooKeeper
>          Issue Type: Sub-task
>          Components: tests
>    Affects Versions: 3.5.0
>            Reporter: Hongchao Deng
>            Assignee: Hongchao Deng
>            Priority: Blocker
>             Fix For: 3.5.0
>
>
> Before 3.5.x, users define zoo.cfg with "clientPort" parameter which is used 
> to identify on which port the server is serving clients.
> After upgrading to 3.5.x, the new format:
> {noformat}
> server.$id=$addr:$port1:$port2[:$role];[$cliAddr:]$cliPort
> {noformat}
> force users to define all the client ports on the entire ZK ensemble.
> The goal of this issue is to preserve backward compatibility upgrading 3.4 to 
> 3.5.
> 1. when a user defines an old-style config file, it should function the same 
> as the old way -- It should use clientPort variable and shouldn't create a 
> dynamic file.
> 2. when a user with old-style config file tries to do reconfig relevant jobs, 
> it should stop him and give out a warning.



--
This message was sent by Atlassian JIRA
(v6.2#6252)