Giridharan Kesavan
added a comment - 16/Nov/11 20:02 - edited this requires applying/back-porting the following list of patches from 3.4 to 3.3 branch
ZOOKEEPER-905
ZOOKEEPER-796
ZOOKEEPER-983
ZOOKEEPER-976
ZOOKEEPER-1013
ZOOKEEPER-1012
ZOOKEEPER-1061
ZOOKEEPER-1074
ZOOKEEPER-1119
I would upload one single patch if that make things easier..

4. I'm not sure I understand the logic of creating ZOO_DATADIR ONLY when ZOOPIDFILE is not defined. In fact,
I a production deployment any attempt at mkdir $ZOO_DATADIR/mkdir -p $(dirname "$ZOOPIDFILE") is very likely
to fail and hence these at least need to be handled gracefully.

Patrick Hunt
added a comment - 16/Nov/11 22:34 1) Let's change datadir like we did in 3.4/trunk (tmp).
2) I don't understand this change, it's for mac but seems to break other things? (see ZOOKEEPER-905 )
Is there a better way to work around this on mac?
Can we drop this change from the patch?
3) ?
4) ?

2) readlink -f causes to follow symlink recursively. It is not supported on Mac. If we are just doing back port, we should follow it strictly without making more variants that can potentially lose track. We can be sure that both 3.4 and 3.3.4 would behave the same for 1 level symlink.

3) The patch is right, it will use user input. Why show user input again?

4) Again, it's strict porting. Any corner case should be addressed in trunk then backport to avoid fragmented branches.

Eric Yang
added a comment - 16/Nov/11 23:40 1) +1 on datadir=/tmp
2) readlink -f causes to follow symlink recursively. It is not supported on Mac. If we are just doing back port, we should follow it strictly without making more variants that can potentially lose track. We can be sure that both 3.4 and 3.3.4 would behave the same for 1 level symlink.
3) The patch is right, it will use user input. Why show user input again?
4) Again, it's strict porting. Any corner case should be addressed in trunk then backport to avoid fragmented branches.

Patrick Hunt
added a comment - 17/Nov/11 00:17 Here's my suggestion. Giri lmk if this makes sense for you.
1) update this patch to drop 2/3/4 changes
2) create new jira(s) for 2/3/4 against 3.3.5/3.4.1/3.5.0(trunk) in order to get those fixed/addressed in later versions.
Giri can you do 1 & 2? Subsequently i'll review this patch for commit in 3.3.4
Thanks!