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 create another candidate once these 2 issues are fixed.


On Tue, Apr 21, 2015 at 11:09 AM, Michi Mutsuzaki <[email protected]> wrote:
> Thanks Pat, I'll update winconfig.h and the notice file.
>
> On Tue, Apr 21, 2015 at 10:53 AM, Patrick Hunt <[email protected]> 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 <[email protected]
>>> wrote:
>>
>>> On 20 April 2015 at 13:03, Raúl Gutiérrez Segalés <[email protected]>
>>> 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 <[email protected]>
>>> 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
>>> >>
>>> >
>>> >
>>>

Reply via email to