[
https://issues.apache.org/jira/browse/ZOOKEEPER-1989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14074855#comment-14074855
]
Hongchao Deng commented on ZOOKEEPER-1989:
------------------------------------------
[~shralex]
Right.. I think preventing version from being written to disk sounds like a
hackish way to fix the problem.
I am thinking about making a config compatibility version. Something looks like:
{code}
version = parseConfig();
version.match {
ReconfigDisabled => v0();
Reconfig => v1();
IfMoreVersions...
}
{code}
So that now different versions is "sandboxed" and simplify workflow and
decouple functionality.
This requires considerable amount of work to change the codebase... Let me
think about more and definitely more discussion is desired.
> 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)
