[CANCEL][VOTE] Release 1.8.0, release candidate #4

2019-04-03 Thread Aljoscha Krettek
I’m hereby canceling the vote for Flink 1.8.0 RC4 in favour of a new RC that I will create shortly now that the blockers are resolved. > On 1. Apr 2019, at 13:21, Till Rohrmann wrote: > > Thanks for reporting this problem and opening a JIRA issue. I've created a > fix for the problem [1]. > >

Re: [VOTE] Release 1.8.0, release candidate #4

2019-04-01 Thread Till Rohrmann
Thanks for reporting this problem and opening a JIRA issue. I've created a fix for the problem [1]. [1] https://github.com/apache/flink/pull/8096 Cheers, Till On Mon, Apr 1, 2019 at 12:30 AM Richard Deurwaarder wrote: > Hello @Aljoscha and @Rong, > > I've described the problem in the mailing

Re: [VOTE] Release 1.8.0, release candidate #4

2019-04-01 Thread Richard Deurwaarder
Hello @Aljoscha and @Rong, I've described the problem in the mailing list[1] and on stackoverflow[2] before. But the gist is: If there's a firewall between the yarn cluster and the machine submitting the job, we need to be able to set a fixed port (or range of ports) for REST communication with

Re: [VOTE] Release 1.8.0, release candidate #4

2019-03-30 Thread Rong Rong
Hi @Aljoscha, Based on the previous commit [1] that adds the random port selection code, it seems like the important part is to unset whatever 'rest.port' setting previously done. I don't think the current way of setting the BIND_PORT actually overrides any existing PORT setting. However, I

Re: [VOTE] Release 1.8.0, release candidate #4

2019-03-30 Thread Aljoscha Krettek
@Richard Did this work for you previously? From the change, it seems that the port was always set to 0 on YARN even before. > On 28. Mar 2019, at 16:13, Richard Deurwaarder wrote: > > -1 (non-binding) > > - Ran integration tests locally (1000+) of our flink job, all succeeded. > - Attempted

Re: [VOTE] Release 1.8.0, release candidate #4

2019-03-30 Thread Aljoscha Krettek
Thanks everyone, for discovering these! @Richard Could you open a Jira issue for this and mark it as blocking? > On 29. Mar 2019, at 09:22, Tzu-Li (Gordon) Tai wrote: > > @Yu discovered this issue, which IMO is probably a blocker for the > release:

Re: [VOTE] Release 1.8.0, release candidate #4

2019-03-29 Thread Tzu-Li (Gordon) Tai
@Yu discovered this issue, which IMO is probably a blocker for the release: https://issues.apache.org/jira/browse/FLINK-12064. The bug is a regression caused by previous state backend refactorings, which can result in incorrect representation of the schema of serialized keys in state because the

Re: [VOTE] Release 1.8.0, release candidate #4

2019-03-28 Thread Richard Deurwaarder
-1 (non-binding) - Ran integration tests locally (1000+) of our flink job, all succeeded. - Attempted to run job on hadoop, failed. It failed because we have a firewall in place and we cannot set the rest port to a specific port/port range. Unless I am mistaken, it seems like FLINK-11081 broke

Re: [VOTE] Release 1.8.0, release candidate #4

2019-03-28 Thread Tzu-Li (Gordon) Tai
+1 (binding) Functional checks: - Built Flink from source (`mvn clean verify`) locally, with success - Ran end-to-end tests locally for 5 times in a loop, no attempts failed (Hadoop 2.8.4, Scala 2.12) - Manually tested state schema evolution for POJO. Besides the tests that @Congxian already

Re: [VOTE] Release 1.8.0, release candidate #4

2019-03-28 Thread Tzu-Li (Gordon) Tai
@Shaoxuan The drop in the serializerAvro benchmark, as explained earlier in previous voting threads of earlier RCs, was due to a slower job initialization phase caused by slower deserialization of the AvroSerializer. Piotr also pointed out that after the number of records was increased in the

Re: [VOTE] Release 1.8.0, release candidate #4

2019-03-27 Thread Aljoscha Krettek
By now, I'm reasonably sure that the test instabilities on the end-to-end test are only instabilities. I pushed changes to increase timeouts to make the tests more stable. As in any project, there will always be bugs but I think we could release this RC4 and be reasonably sure that it works

Re: [VOTE] Release 1.8.0, release candidate #4

2019-03-27 Thread Congxian Qiu
+1 (non-binding) • checked signature and checksum  ok • mvn clean package -DskipTests ok • Run job on yarn ok • Test state migration with POJO type (both heap and rocksdb) ok • - 1.6 -> 1.8 • - 1.7 -> 1.8 • - 1.8 -> 1.8 Best, Congxian On Mar 27, 2019, 10:26 +0800, vino yang , wrote: > +1

Re: [VOTE] Release 1.8.0, release candidate #4

2019-03-26 Thread vino yang
+1 (non-binding) - checked JIRA release note - ran "mvn package -DskipTests" - checked signature and checksum - started a cluster locally and ran some examples in binary - checked web site announcement's PR Best, Vino Xiaowei Jiang 于2019年3月26日周二 下午8:20写道: > +1 (non-binding) > > - checked

Re: [VOTE] Release 1.8.0, release candidate #4

2019-03-26 Thread Xiaowei Jiang
+1 (non-binding) - checked checksums and GPG files - build from source successfully- run end-to-end precommit tests successfully- run end-to-end nightly tests successfully Xiaowei On Tuesday, March 26, 2019, 8:09:19 PM GMT+8, Yu Li wrote: +1 (non-binding) - Checked release notes: OK

Re: [VOTE] Release 1.8.0, release candidate #4

2019-03-26 Thread Yu Li
+1 (non-binding) - Checked release notes: OK - Checked sums and signatures: OK - Source release - contains no binaries: OK - contains no 1.8-SNAPSHOT references: OK - build from source: OK (8u101) - mvn clean verify: OK (8u101) - Binary release - no examples appear to be

Re: [VOTE] Release 1.8.0, release candidate #4

2019-03-26 Thread Kurt Young
+1 (non-binding) Checked items: - checked checksums and GPG files - verified that the source archives do not contains any binaries - checked that all POM files point to the same version - build from source successfully Best, Kurt On Tue, Mar 26, 2019 at 10:57 AM Shaoxuan Wang wrote: > +1

Re: [VOTE] Release 1.8.0, release candidate #4

2019-03-25 Thread Shaoxuan Wang
+1 (non-binding) I tested RC4 with the following items: - Maven Central Repository contains all artifacts - Built the source with Maven (ensured all source files have Apache headers), and executed built-in tests via "mvn clean verify" - Manually executed the tests in IntelliJ IDE - Verify that

Re: [VOTE] Release 1.8.0, release candidate #4

2019-03-25 Thread jincheng sun
Hi Aljoscha, I think you are right, increase the timeout config will fix this issue. this depends on the resource of Travis. I would like share some phenomenon during my test (not the flink problem) as follows: :-) During my testing, `mvn clean verify` and `nightly end-to-end test ` both

Re: [VOTE] Release 1.8.0, release candidate #4

2019-03-25 Thread Aljoscha Krettek
Thanks for the testing done so far! There has been quite some flakiness on Travis lately, see here: https://travis-ci.org/apache/flink/branches . I’m a bit hesitant to release in this state. Looking at the tests you can see that all of the

Re: [VOTE] Release 1.8.0, release candidate #4

2019-03-25 Thread jincheng sun
Great thanks for preparing the RC4 of Flink 1.8.0, Aljoscha! +1 (non-binding) I checked the functional things as follows(Without performance verification): 1. Checking Artifacts: 1). Download the release source code - SUCCESS 2). Check Source release flink-1.8.0-src.tgz.sha512 -

Re: [VOTE] Release 1.8.0, release candidate #4

2019-03-25 Thread Piotr Nowojski
+1 from my side. Previously spotted performance regression seems to be gone, or mostly gone. Piotrek > On 21 Mar 2019, at 17:52, Aljoscha Krettek wrote: > > Hi everyone, > Please review and vote on the release candidate 4 for Flink 1.8.0, as follows: > [ ] +1, Approve the release > [ ] -1, Do

[VOTE] Release 1.8.0, release candidate #4

2019-03-21 Thread Aljoscha Krettek
Hi everyone, Please review and vote on the release candidate 4 for Flink 1.8.0, as follows: [ ] +1, Approve the release [ ] -1, Do not approve the release (please provide specific comments) The complete staging area is available for your review, which includes: * JIRA release notes [1], * the