Hi, It looks like we have couple of jira issues ready to check in to the branch-3.5 like, ZOOKEEPER-2174, ZOOKEEPER-2062 etc
But these are not blockers for 3.5.1 release, should we wait for the 3.5.1 release and then push/commit these kinda issues into the project ? FYI: Presently we have only two issues marked for 3.5.1 -> ZOOKEEPER-2171(required) and ZOOKEEPER-2124. Thanks & Regards, Rakesh On Tue, Apr 28, 2015 at 5:00 AM, Michi Mutsuzaki <mutsuz...@gmail.com> wrote: > You can go a head and check it in. > > On Mon, Apr 27, 2015 at 11:40 AM, Camille Fournier <cami...@apache.org> > wrote: > > Is it a problem if I put ZOOKEEPER-2173 into the 3.5 branch before this > > release? https://issues.apache.org/jira/browse/ZOOKEEPER-2173 > > > > On Mon, Apr 27, 2015 at 2:08 AM, Raúl Gutiérrez Segalés < > r...@itevenworks.net > >> wrote: > > > >> Hi Michi, > >> > >> On 26 April 2015 at 14:44, Michi Mutsuzaki <mutsuz...@gmail.com> wrote: > >> > >> > Thank you everybody for voting. We are *not* releasing this candidate. > >> > There are 2 things to fix: > >> > > >> > - Update winconfig.h and the notice file (Michi) > >> > - https://issues.apache.org/jira/browse/ZOOKEEPER-2171 (Raul?) > >> > > >> > >> I'll get to ZK-2171 tomorrow. > >> > >> > >> -rgs > >> > >> > >> > >> > I'll create another candidate once these 2 issues are fixed. > >> > > >> > > >> > On Tue, Apr 21, 2015 at 11:09 AM, Michi Mutsuzaki < > mutsuz...@gmail.com> > >> > wrote: > >> > > Thanks Pat, I'll update winconfig.h and the notice file. > >> > > > >> > > On Tue, Apr 21, 2015 at 10:53 AM, Patrick Hunt <ph...@apache.org> > >> wrote: > >> > >> Looks like version strings are in src/c/include/winconfig.h that > need > >> > to be > >> > >> updated. They are still listed as 3.5.0. > >> > >> > >> > >> I think you'll need to spin a new RC to address this. > >> > >> > >> > >> You might update the notice file to include 2015 at the same time > >> (not a > >> > >> blocker typically though). > >> > >> > >> > >> Patrick > >> > >> > >> > >> On Mon, Apr 20, 2015 at 5:41 PM, Raúl Gutiérrez Segalés < > >> > r...@itevenworks.net > >> > >>> wrote: > >> > >> > >> > >>> On 20 April 2015 at 13:03, Raúl Gutiérrez Segalés < > >> r...@itevenworks.net > >> > > > >> > >>> wrote: > >> > >>> > >> > >>> > -1, alas. > >> > >>> > > >> > >>> > I think ZOOKEEPER-1506 could be problematic for some setups. > After > >> a > >> > >>> > couple of elections with a cluster of 5 participants and one > >> > observer, I > >> > >>> > end up with a participant that's unable to find the leader > because > >> it > >> > >>> does > >> > >>> > a reverse lookup (IP -> hostname) and ends up with a bogus > hostname > >> > that > >> > >>> it > >> > >>> > can't resolve: > >> > >>> > > >> > >>> > https://gist.github.com/rgs1/d11822799fdbbfa5d5f2 > >> > >>> > > >> > >>> > I don't think the reverse lookup from QuorumCnxManager was done > >> > before, > >> > >>> > nor that it should be done. So it could cause issues in places > >> where > >> > >>> > reverse lookups aren't fully working. Surely, we could argue > that > >> > it's a > >> > >>> > DNS setup issue but I think we should avoid the extra lookup if > >> > possible. > >> > >>> > > >> > >>> > I'll dig in a bit deeper and try to come with a deterministic > >> repro. > >> > >>> > > >> > >>> > >> > >>> Commented on ZOOKEEPER-1506: turns out that my issue was with > reverse > >> > >>> lookup calls that were not introduced by that patch. They seem to > >> have > >> > been > >> > >>> introduced by ZOOKEEPER-107, so they have been around for a while. > >> > >>> > >> > >>> The tl;dr is that if your resolvers give you bad reverse names, > >> you'll > >> > have > >> > >>> issues. It would nice to avoid these reverse lookups, so I > created: > >> > >>> > >> > >>> https://issues.apache.org/jira/browse/ZOOKEEPER-2171 > >> > >>> > >> > >>> After sorting this issue, I tested the following: > >> > >>> > >> > >>> * many elections (which look quick) > >> > >>> * creating and deleting ephemerals in a loop (via zk-shell) > >> > >>> * phunt's smoke test scripts (comparable results to 3.5.0) > >> > >>> * partitioning and unpartioning an attached observer > >> > >>> * use zktraffic's fle-dump & zab-dump to inspect if there were any > >> > bogus > >> > >>> FLE votes or ZAB messages [0] > >> > >>> > >> > >>> All of this looks good! So +1 now :-) > >> > >>> > >> > >>> > >> > >>> -rgs > >> > >>> > >> > >>> p.s.: fwiw, here's my test setup: > http://itevenworks.net/zk-releases > >> > >>> > >> > >>> [0] https://github.com/twitter/zktraffic > >> > >>> > >> > >>> > >> > >>> > >> > >>> > > >> > >>> > -rgs > >> > >>> > > >> > >>> > > >> > >>> > > >> > >>> > > >> > >>> > On 12 April 2015 at 14:58, Michi Mutsuzaki < > mi...@cs.stanford.edu> > >> > >>> wrote: > >> > >>> > > >> > >>> >> This is a release candidate for 3.5.1-alpha. The full release > >> notes > >> > is > >> > >>> >> available at: > >> > >>> >> > >> > >>> >> > >> > >>> > >> > > >> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12326786 > >> > >>> >> > >> > >>> >> *** Please download, test and vote by April 25th 2015, 23:59 > >> UTC+0. > >> > *** > >> > >>> >> > >> > >>> >> Source files: > >> > >>> >> > >> http://people.apache.org/~michim/zookeeper-3.5.1-alpha-candidate-0/ > >> > >>> >> > >> > >>> >> Maven staging repo: > >> > >>> >> > >> > >>> >> > >> > >>> > >> > > >> > https://repository.apache.org/content/groups/staging/org/apache/zookeeper/zookeeper/3.5.1-alpha/ > >> > >>> >> > >> > >>> >> The tag to be voted upon: > >> > >>> >> > >> https://svn.apache.org/repos/asf/zookeeper/tags/release-3.5.1-rc0/ > >> > >>> >> > >> > >>> >> ZooKeeper's KEYS file containing PGP keys we use to sign the > >> > release: > >> > >>> >> http://www.apache.org/dist/zookeeper/KEYS > >> > >>> >> > >> > >>> >> Should we release this candidate? > >> > >>> >> > >> > >>> >> --Michi > >> > >>> >> > >> > >>> > > >> > >>> > > >> > >>> > >> > > >> >
