[
https://issues.apache.org/jira/browse/ZOOKEEPER-1989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14074866#comment-14074866
]
Alexander Shraer commented on ZOOKEEPER-1989:
---------------------------------------------
Sure, that's possible. You could set the version to the special number in
Leader.lead() where I pointed out.
You get a bit more info this way (for example a follower may know that the
leader is in backward compatibility mode).
Personally I still think that simply checking that the config has all ports
specified before the server boots is a much better solution even if it breaks
backward compatibility a bit. In order to upgrade users will have to restart
the server anyway, so when they do we'll just tell them "please specify all
client ports in the following format: ...".
> 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)
