Re: [DISCUSS] solve unstable build capacity problem on TravisCI

i.com/plans [2] https://docs.travis-ci.com/user/migrate/open-source-repository-migration On Sat, Jun 29, 2019 at 8:39 AM Chesnay Schepler <mailto:ches...@apache.org>> wrote: So yes, the Jenkins job keeps pulling the state from Travis until it finishes. Note sure I'm com

Re: [DISCUSS] solve unstable build capacity problem on TravisCI

As a short-term stopgap, since we can assume this issue to become much worse in the following days/weeks, we could disable IT cases in PRs and only run them on master. On 02/07/2019 12:03, Chesnay Schepler wrote: People really have to stop thinking that just because something works for us it

Re: [DISCUSS] solve unstable build capacity problem on TravisCI

that Spark is on its own build infra. If we all agree that funding our own build infra, I'd be glad to help investigate any potential options after releasing 1.9 since I'm super busy with 1.9 now. [1] https://issues.apache.org/jira/browse/INFRA-18533 On Tue, Jul 2, 2019 at 4:46 AM C

Re: [DISCUSS] Publish the PyFlink into PyPI

release due to 2.13 is available in early June.) From the points of my view, for now, we can only release the scala_2.11 version, due to scala_2.11 is our default version in Flink. 3. Legal problems of publishing to PyPI As @Chesnay Schepler pointed out in FLINK-13011[3], publishing PyFli

Re: [DISCUSS] Publish the PyFlink into PyPI

scala 2.11). Regards, Dian 在 2019年7月3日，下午7:13，Chesnay Schepler 写道： The existing artifact in the pyflink project was neither released by the Flink project / anyone affiliated with it nor approved by the Flink PMC. As such, if we were to use this account I believe we should delete it to not mi

[VOTE] Migrate to sponsored Travis account

lt;https://ci.ursalabs.org/#/> [2] https://github.com/ursa-labs/ursabot [3] https://docs.travis-ci.com/user/migrate/open-source-repository-migration [4] https://docs.travis-ci.com/user/migrate/open-source-on-travis-ci-com On Wed, Jul 3, 2019 at 12:01 AM Chesnay Schepler <mailto:ches...@apache.org&

Re: [DISCUSS] A more restrictive JIRA workflow

at a contributor ask a committer for setting the JIRA as unconditional, which is no better than ask a committer for assigning to the contributor. @Timo "More discussion before opening a PR" sounds good. However, it requires more effort/participation from committer's sid

Re: [VOTE] Migrate to sponsored Travis account

not appear possible to configure the Travis account used for a specific repository. So yeah, if we go down this route we may have to pimp the Flinkbot to trigger builds through the Travis REST API. On 04/07/2019 10:46, Chesnay Schepler wrote: I've raised a JIRA <https://issues.ap

Re: [DISCUSS] Flink framework and user log separation

From what I understand this isn't about logging Flink/user messages to different files, but log everything relevant to a specific job to a separate file (including what is being logged in runtime classes, i.e. Tasks, Operators etc.) On 04/07/2019 12:37, Stephan Ewen wrote: Is that something t

Re: [VOTE] Migrate to sponsored Travis account

lock after the next showing up... On 04/07/2019 11:59, Chesnay Schepler wrote: Small update with mostly bad news: INFRA doesn't know whether it is possible, and referred my to Travis support. They did point out that it could be problematic in regards to read/write permissions for the rep

Re: [VOTE] Migrate to sponsored Travis account

/2019 14:06, Chesnay Schepler wrote: Note that the Flinkbot approach isn't that trivial either; we can't _just_ trigger builds for a branch in the apache repo, but would first have to clone the branch/pr into a separate repository (that is owned by the github account that the travis accoun

[RESULT][VOTE] Migrate to sponsored Travis account

s in the future. I'll setup a repo with the source of the bot later. On 04/07/2019 10:46, Chesnay Schepler wrote: I've raised a JIRA <https://issues.apache.org/jira/browse/INFRA-18703>with INFRA to inquire whether it would be possible to switch to a different Travis account, and if

Re: [RESULT][VOTE] Migrate to sponsored Travis account

Chesnay Schepler 于2019年7月8日周一 上午5:01写道： The vote has passed unanimously in favor of migrating to a separate Travis account. I will now set things up such that no PullRequest is no longer run on the ASF servers. This is a major setup in reducing our usage of ASF resources. For the time being

Re: [RESULT][VOTE] Migrate to sponsored Travis account

I have temporarily re-enabled running PR builds on the ASF account; migrating to the Travis subscription caused some issues in the bot that I have to fix first. On 07/07/2019 23:01, Chesnay Schepler wrote: The vote has passed unanimously in favor of migrating to a separate Travis account. I

Re: [RESULT][VOTE] Migrate to sponsored Travis account

The kinks have been worked out; the bot is running again and pr builds are yet again no longer running on ASF resources. PRs are mirrored to: https://github.com/flink-ci/flink Bot source: https://github.com/flink-ci/ci-bot On 08/07/2019 17:14, Chesnay Schepler wrote: I have temporarily re

Re: Flink 1.8.1 release tag missing?

Yes, it appears the 1.8.1 tag is missing. The 1.8.1-rc1 tag is an equivalent that you can use for the time being. Alternatively you could of course also use the source release to build the connector. @jincheng Could you add the proper 1.8.1 tag? On 09/07/2019 16:38, Bekir Oguz wrote: Hi, I

Re: [RESULT][VOTE] Migrate to sponsored Travis account

On Tue, Jul 9, 2019 at 3:27 AM Chesnay Schepler wrote: The kinks have been worked out; the bot is running again and pr builds are yet again no longer running on ASF resources. PRs are mirrored to: https://github.com/flink-ci/flink Bot source: https://github.com/flink-ci/ci-bot On 08/07/2019

Re: [ANNOUNCE] Feature freeze for Apache Flink 1.9.0 release

could make good use for another week, I think it definitely makes sense to postpone the feature freeze. The new date for feature freeze and feature branch cut for 1.9.0 will be *July 5*. Please update on this thread if there are any further concerns! Cheers, Gordon On Tue, Jun 25, 2019 at 9:05

Re: [DISCUSS] Flink project bylaws

The emeritus stuff seems like unnecessary noise. There's a bunch of subtle changes in the draft compared to existing "conventions"; we should find a way to highlight these and discuss them one by one. On 11/07/2019 14:29, Robert Metzger wrote: Thank you Becket for kicking off this discussion

Re: [DISCUSS] Flink project bylaws

k another committer for feedback or not. Hence, I would not enforce that we strictly need a +1 from a committer if the author is a committer but of course encourage it if capacities exist. Cheers, Till On Thu, Jul 11, 2019 at 3:08 PM Chesnay Schepler wrote: The emeritus stuff seems l

Re: [DISCUSS] Create "flink-playgrounds" repository

Wouldn't this qualify for releasing snapshot artifacts to users? (Which, you know, shouldn't be done?) On 12/07/2019 11:55, Robert Metzger wrote: I will request the repo now, so that you can continue working on the documentation (thanks for that again :) ) I actually like Xuefu's idea of maki

Re: [DISCUSS] Create "flink-playgrounds" repository

link PMC. Since this is not on the official download page, and clearly in the context of a "playground" or "demonstration", people will not assume a proper release. Do you think that is okay, or should we reach out to somebody at the foundation? On Fri, Jul 12, 2019

CiBot Update

Hello all, on Thursday i pushed an update to the CiBot so that it * only maintains a single comment, updating it for each new build * also links in-progress/queued builds, instead of just finished ones. The update also included a bug that causes the bot to not recognize which commits have be

Re: CiBot Update

Yes. On 13/07/2019 01:56, Bowen Li wrote: * only maintains a single comment, updating it for each new build * also links in-progress/queued builds, instead of just finished ones. Want to clarify that the above changes still hold? On Fri, Jul 12, 2019 at 3:56 PM Chesnay Schepler wrote

Re: CiBot Update

but the travis build actually passed successfully 14 hours ago [2]. [1] https://github.com/apache/flink/pull/8920#issuecomment-510405859 [2] https://travis-ci.com/flink-ci/flink/builds/119001147 On Fri, Jul 12, 2019 at 11:00 PM Chesnay Schepler wrote: Yes. On 13/07/2019 01:56, Bowen Li wro

Re: Flink benchmark Jenkins is broken due to missing 1.10 snapshots

It is documented in the release guide that a new jenkins deployment must be setup when creating a new release branch, and even contains step-by-step instructions for doing so. @Kurt @Gordon please fix this On 12/07/2019 20:10, Yu Li wrote: Hi All, I just found our flink benchmark Jenkins bui

Re: Flink benchmark Jenkins is broken due to missing 1.10 snapshots

Please also setup the 1.9 travis cron branch. On 15/07/2019 09:46, Chesnay Schepler wrote: It is documented in the release guide that a new jenkins deployment must be setup when creating a new release branch, and even contains step-by-step instructions for doing so. @Kurt @Gordon please fix

Re: Flink benchmark Jenkins is broken due to missing 1.10 snapshots

ordon for fixing this! Best, Kurt On Mon, Jul 15, 2019 at 5:43 PM Tzu-Li (Gordon) Tai wrote: Done. Thanks for the reminder and help with the Jenkins deployment setup! Cheers, Gordon On Mon, Jul 15, 2019 at 3:54 PM Chesnay Schepler wrote: Please also setup the 1.9 travis cron branch. On

Re: Flink benchmark Jenkins is broken due to missing 1.10 snapshots

created a PR (https://github.com/dataArtisans/flink-benchmarks/pull/29) to revise pom.xml of `flink-benchmarks` accordingly, and need someone to help merge it. @Chesnay Schepler Best, Haobo At 2019-07-15 19:01:57, "Yu Li" wrote: >Thanks for the note Chesnay, will wait and report back

Re: [DISCUSS] A more restrictive JIRA workflow

a ticket I opened https://issues.apache.org/jira/browse/INFRA-18644 a long time ago :) On Thu, Jul 4, 2019 at 10:47 AM Chesnay Schepler wrote: @Robert what's the state here? On 24/06/2019 16:16, Robert Metzger wrote: Hey all, I would like to drive this discussion to an end soon. I

Re: [DISCUSS] A more restrictive JIRA workflow

Do our contribution guidelines contain anything that should be updated? On 18/07/2019 12:24, Chesnay Schepler wrote: Sounds good to me. On 18/07/2019 12:07, Robert Metzger wrote: Infra has finally changed the permissions. I just announced the change in a separate email [1]. One thing I

Re: [DISCUSS] A more restrictive JIRA workflow

ters can assign a Jira ticket." I think the corresponding update has been done. Best, tison. Chesnay Schepler 于2019年7月18日周四 下午6:25写道： Do our contribution guidelines contain anything that should be updated? On 18/07/2019 12:24, Chesnay Schepler wrote: Sounds good to me. On 18/07/2019 1

Re: flink-mapr-fs failed in travis

I did modify the .travis.yml do activate the unsafe-mapr-repo profile; did I modified the wrong profile?... On 19/07/2019 07:57, Jark Wu wrote: It seems that it is introduced by this commit: https://github.com/apache/flink/commit/5c36c650e6520d92191ce2da33f7dcae774319f6 Hi @Chesnay Schepler

Re: flink-mapr-fs failed in travis

Ah, I added it to the common options in the travis_manv_watchdog.sh . On 19/07/2019 09:58, Chesnay Schepler wrote: I did modify the .travis.yml do activate the unsafe-mapr-repo profile; did I modified the wrong profile?... On 19/07/2019 07:57, Jark Wu wrote: It seems that it is introduced

Re: flink-mapr-fs failed in travis

I think I found the issue; I forgot to update travis_controller.sh . On 19/07/2019 10:02, Chesnay Schepler wrote: Ah, I added it to the common options in the travis_manv_watchdog.sh . On 19/07/2019 09:58, Chesnay Schepler wrote: I did modify the .travis.yml do activate the unsafe-mapr-repo

[NOTICE] SSL issue when building flink-mapr-fs

Hello, the Flink PMC was a while ago informed about a security risk in our build process, as we were accessing various maven repositories without HTTPS. This issue was resolved in FLINK-12578 for 1.7 on-wards. However, there is an ongoing issue with the MapR repository where you may run into

Re: [DISCUSS] Publish the PyFlink into PyPI

cala (and thus depend on specific scala versions) can still download from Apache or build themselves. Best, Stephan On Thu, Jul 4, 2019 at 9:51 AM jincheng sun wrote: Hi All, Thanks for the feedback @Chesnay Schepler @Dian! I think using `apache-flink` for the project name also makes sense

Re: [Requirement] CI report

Noted, I'll see what I can do. On 23/07/2019 10:15, Zili Chen wrote: Hi, Currently, our flinkbot updates CI report on status changing. However, it updates via editing GitHub comment, which would not send a notification to pr creator once status updated. Said the "PENDING" status is not quite

Re: Something wrong with travis?

(the build overview https://travis-ci.org/apache/flink/builds/549534489). For those non-committers, including me, we have to close-reopen the PR or push another commit to re-trigger the PR check🙁 Best Yun Tang From: Chesnay Schepler Sent: Wednesday, June 19

Re: REST API / JarRunHandler: More flexibility for launching jobs

Couldn't the beam job server use the same work-around we're using in the JarRunHandler to get access to the JobGraph? On 26/07/2019 17:38, Thomas Weise wrote: Hi Till, Thanks for taking a look! The Beam job server does not currently have the ability to just output the job graph (and related a

Re: [DISCUSS] ARM support for Flink

We (as in the Flink PMC) cannot add apps to the GitHub repo; please check first with INFRA whether these CI systems are allowed. On 30/07/2019 03:44, Xiyuan Wang wrote: Hi Stephan, Maybe I misled you in the previous email. We don't need to migrate CI completely, travis-ci is still there work

Re: [DISCUSS] ARM support for Flink

Please open a JIRA with INFRA and ask whether OpenLab/Drone are supported by INFRA. On 01/08/2019 04:16, Xiyuan Wang wrote: Thanks for your reply. We are now keeping investigating and debugging Flink on ARM. It's hard for us to say How many kinds of test are enough for ARM support at this mom

Re: [DISCUSS][CODE STYLE] Breaking long function argument lists and chained method calls

Just so everyone remembers: Any suggested code-style should be a) configurable in the IDE (otherwise we'll never be able to auto-format) b) be verifiable via checkstyle (otherwise we'll end up manually checking for code-style again) On 02/08/2019 03:20, SHI Xiaogang wrote: Hi Andrey, Thanks

Re: [RESULT][VOTE] Migrate to sponsored Travis account

ll in pending and not canceled. Before we fix that, we can manually cancel some old jobs to save build resource. Best, Jark On Wed, 10 Jul 2019 at 16:17, Chesnay Schepler wrote: Your best bet would be to check the first commit in the PR and check the parent commit. To re-run things, you will ha

Re: [RESULT][VOTE] Migrate to sponsored Travis account

Update: Implemented and deployed. On 02/08/2019 12:11, Jark Wu wrote: Wow. That's great! Thanks Chesnay. On Fri, 2 Aug 2019 at 17:50, Chesnay Schepler <mailto:ches...@apache.org>> wrote: I'm currently modifying the cibot to do this automatically; should be fi

Re: flink-mapr-fs failed in travis

. https://travis-ci.org/apache/flink/builds/566447083 Thanks Nico On 19/07/2019 10:40, Chesnay Schepler wrote: I think I found the issue; I forgot to update travis_controller.sh . On 19/07/2019 10:02, Chesnay Schepler wrote: Ah, I added it to the common options in the travis_manv_watchdog.sh . On

[DISCUSS] Repository split

Hello everyone, The Flink project sees an ever-increasing amount of dev activity, both in terms of reworked and new features. This is of course an excellent situation to be in, but we are getting to a point where the associate downsides are becoming increasingly troublesome. The ever increa

Re: [DISCUSS] Repository split

org/jira/browse/FLINK-13593 <https://issues.apache.org/jira/browse/FLINK-13593> On 7 Aug 2019, at 13:14, Chesnay Schepler wrote: Hello everyone, The Flink project sees an ever-increasing amount of dev activity, both in terms of reworked and new features. This is of course an excellent

Re: [DISCUSS] Repository split

Bowen I have implemented and deployed your suggestion to cancel Travis builds if the associated PR has been closed. On 07/08/2019 13:14, Chesnay Schepler wrote: Hello everyone, The Flink project sees an ever-increasing amount of dev activity, both in terms of reworked and new features. T

[DISCUSS] Reducing build times

Hello everyone, improving our build times is a hot topic at the moment so let's discuss the different ways how they could be reduced. Current state: First up, let's look at some numbers: 1 full build currently consumes 5h of build time total ("total time"), and in the ideal case tak

Re: Watermarks not propagated to WebUI?

I remember an issue regarding the watermark fetch request from the WebUI exceeding some HTTP size limit, since it tries to fetch all watermarks at once, and the format of this request isn't exactly efficient. Querying metrics for individual operators still works since the request is small enou

Re: [VOTE] Apache Flink Release 1.9.0, release candidate #2

The licensing items aren't a problem; we don't care about Flink modules in NOTICE files, and we don't have to update the source-release licensing since we don't have a pre-built version of the WebUI in the source. On 15/08/2019 15:22, Kurt Young wrote: After going through the licenses, I foun

[DISCUSS] Release flink-shaded 8.0

Hello, I would like to kick off the next flink-shaded release next week. There are 2 ongoing efforts that are blocked on this release: * [FLINK-13467] Java 11 support requires a bump to ASM to correctly handle Java 11 bytecode * [FLINK-11767] Reworking the typeSerializerSnapshotMigrationT

Re: [DISCUSS] Reducing build times

There appears to be a general agreement that 1) should be looked into; I've setup a branch with fork reuse being enabled for all tests; will report back the results. On 15/08/2019 09:38, Chesnay Schepler wrote: Hello everyone, improving our build times is a hot topic at the moment so

Re: [VOTE] Flink Project Bylaws

I'm very late to the party, but isn't it a bit weird that we're using a voting scheme that isn't laid out in the bylaws? Additionally, I would heavily suggest to CC priv...@flink.apache.org, as we want as many PMC as possible to look at this. (I would regard the this point as a reason for delay

Re: [VOTE] Flink Project Bylaws

.@flink.apache.org in the future. I wouldn't say it is a must though. The voting scheme requires that every PMC member has to be reached out directly, via a private address if he/she did not vote in a thread. So every PMC member should be aware of the voting thread. Best, Dawid On 16/08/2019

Re: [DISCUSS] Reducing build times

:43, Chesnay Schepler wrote: There appears to be a general agreement that 1) should be looked into; I've setup a branch with fork reuse being enabled for all tests; will report back the results. On 15/08/2019 09:38, Chesnay Schepler wrote: Hello everyone, improving our build times is a hot

Re: [VOTE] Flink Project Bylaws

+1 (binding) Although I think it would be a good idea to always cc priv...@flink.apache.org when modifying bylaws, if anything to speed up the voting process. On 16/08/2019 11:26, Ufuk Celebi wrote: +1 (binding) – Ufuk On Wed, Aug 14, 2019 at 4:50 AM Biao Liu wrote: +1 (non-binding) T

Re: [DISCUSS] Reducing build times

On Fri, Aug 16, 2019 at 1:36 PM Chesnay Schepler wrote: Update: TL;DR: table-planner is a good candidate for enabling fork reuse right away, while flink-tests has the potential for huge savings, but we have to figure out some issues first. Build link: https://travis-ci.org/zentol/flink/builds

Re: [VOTE] FLIP-52: Remove legacy Program interface.

+1 On 21/08/2019 13:23, Timo Walther wrote: +1 Am 21.08.19 um 13:21 schrieb Stephan Ewen: +1 On Wed, Aug 21, 2019 at 1:07 PM Kostas Kloudas wrote: Hi all, Following the FLIP process, this is a voting thread dedicated to the FLIP-52. As shown from the corresponding discussion thread [1],

Re: [VOTE] Apache Flink 1.9.0, release candidate #3

+1 (binding) On 21/08/2019 08:09, Bowen Li wrote: +1 non-binding - built from source with default profile - manually ran SQL and Table API tests for Flink's metadata integration with Hive Metastore in local cluster - manually ran SQL tests for batch capability with Blink planner and Hive integr

Re: [DISCUSS] Release flink-shaded 8.0

ug 16, 2019 at 10:30 AM Chesnay Schepler mailto:ches...@apache.org>> wrote: Hello, I would like to kick off the next flink-shaded release next week. There are 2 ongoing efforts that are blocked on this release:   * [FLINK-13467] Java 11 support requires a bump to ASM

CiBot Update

Hi everyone, this is an update on recent changes to the CI bot. The bot now cancels builds if a new commit was added to a PR, and cancels all builds if the PR was closed. (This was implemented a while ago; I'm just mentioning it again for discoverability) Additionally, starting today you c

Re: [RESULT] [VOTE] Apache Flink 1.9.0, release candidate #3

Ewen - Jark Wu - Vino Yang - Gary Yao - Bowen Li - Chesnay Schepler - Till Rohrmann - Aljoscha Krettek - David Anderson There are no disapproving votes. Thanks everyone who has contributed to this release! I will wait until tomorrow morning for the artifacts to be available in Maven central b

[NOTICE] GitHub service interruption

Hello, GitHub is currently experiencing problems ; so far the one issue we saw ourselves is that Travis builds aren't triggered if a commit is pushed. This affects builds both for branches and pull requests; cron jobs may be fine. @Committers: Please keep this

Re: CiBot Update

vino yang mailto:yanghua1...@gmail.com>> 于2019年8月22日周四 上午8:14写道： +1 for "@flinkbot run travis", it is very convenient. Chesnay Schepler mailto:ches...@apache.org>> 于2019年8月21日周三 下午9:12写道： Hi everyone, this is an update on recent changes to the CI bot. The bo

Re: [DISCUSS] Add ARM CI build to Flink (information-only)

I'm wondering what we are supposed to do if the build fails? We aren't providing and guides on setting up an arm dev environment; so reproducing it locally isn't possible. On 23/08/2019 17:55, Stephan Ewen wrote: Hi all! As part of the Flink on ARM effort, there is a pull request that trigger

[VOTE] Release flink-shaded 8.0, release candidate #1

Hi everyone, Please review and vote on the release candidate #1 for the version 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], *

Re: [DISCUSS] Add ARM CI build to Flink (information-only)

w [1]: https://issues.apache.org/jira/browse/FLINK-13449 https://issues.apache.org/jira/browse/FLINK-13450 [2]: https://issues.apache.org/jira/browse/FLINK-13598 [3]: https://github.com/theopenlab/openlab/issues/new/choose Chesnay Schepler 于2019年8月24日周六 上午12:10写道： I'm wondering w

Re: [DISCUSS] Flink project bylaws

judgement of the committer to respect the components expertise and ongoing development plans (also the de facto current state). 3. Minimum length of 3 days for FLIP I think currently might be problematic/too quick and can lead to problems if respected to the letter. Again I thi

Re: [VOTE] Release flink-shaded 8.0, release candidate #1

wrote: +1 (binding) - I verified the signature and checksum - I eyeballed the list of resolved issues - I checked the maven central artifices Aljoscha On 23. Aug 2019, at 21:05, Chesnay Schepler wrote: Hi everyone, Please review and vote on the release candidate #1 for the version 8.0

[RESULT] [VOTE] flink-shaded 8.0, release candidate #1

|I'm happy to announce that we have unanimously approved this release.| |There are 3 approving votes, 3 of which are binding:| |* Aljoscha| |* Till | |* Chesnay| |There are no disapproving votes.| |Thanks everyone!| On 23/08/2019 21:05, Chesnay Schepler wrote: Hi everyone, Please revie

Re: [PROPOSAL] Force rebase on master before merge

I think this is a non-issue; every committer I know checks beforehand if the build passes. Piotr has provided good arguments for why this approach isn't practical. Additionally, there are simply technical limitations that prevent this from working as expected. a) we cannot attach Travis check

[ANNOUNCE] Apache Flink-shaded 8.0 released

The Apache Flink community is very happy to announce the release of Apache Flink-shaded 8.0. The flink-shaded project contains a number of shaded dependencies for Apache Flink. Apache Flink® is an open-source stream processing framework for distributed, high-performing, always-available, and

State of FLIPs

The following FLIPs are marked as "Under discussion" in the wiki , but actually seem to be in progress (i.e. have open pull requests) and some even  have code merged to master: * FLIP-36 (Interactive Programming)

Re: [DISCUSS] Reducing build times

le 31 CPUs are idling :) ) Let me know what you think about these results. If the community is generally interested in further investigating into that direction, I could look into software to orchestrate this, as well as sponsors for such an infrastructure. [1] https://docs.travis-ci.com/user/refer

Re: [DISCUSS] Contribute Pulsar Flink connector back to Flink

I'm quite worried that we may end up repeating history. There were already 2 attempts at contributing a pulsar connector, both of which failed because no committer was getting involved, despite the contributor opening a dedicated discussion thread about the contribution beforehand and getting

Re: [VOTE] FLIP-61 Simplify Flink's cluster level RestartStrategy configuration

+1 (binding) On 04/09/2019 11:13, Zhu Zhu wrote: +1 (non-binding) Thanks, Zhu Zhu Till Rohrmann 于2019年9月4日周三 下午5:05写道： Hi everyone, I would like to start the voting process for FLIP-61 [1], which is discussed and reached consensus in this thread [2]. Since the change is rather small I'd l

Re: [VOTE] FLIP-62: Set default restart delay for FixedDelay- and FailureRateRestartStrategy to 1s

+1 (binding) On 04/09/2019 11:18, JingsongLee wrote: +1 (non-binding) default 0 is really not user production friendly. Best, Jingsong Lee -- From:Zhu Zhu Send Time:2019年9月4日(星期三) 17:13 To:dev Subject:Re: [VOTE] FLIP-62: Set d

Re: [DISCUSS] FLIP-62: Set default restart delay for FixedDelay- and FailureRateRestartStrategy to 1s

The issue we seem to run into again and again is that we want to try to find a value that provides a good experience when trying out Flink, but also somewhat usable for production users. We should look into solutions for this; maybe having a "recommended" value in the docs would help sufficientl

Re: [DISCUSS] Reducing build times

3.5 hours on that infra (not parallelized at all, no caching). These free machines are very similar to those of Travis, so I expect no build time regressions, if we set it up similarly. On Wed, Sep 4, 2019 at 9:19 AM Chesnay Schepler wrote: Will using more powerful for the project make it more

Re: Fine grained batch recovery vs. native libraries

This sounds like a serious bug, please open a JIRA ticket. On 04/09/2019 13:41, David Morávek wrote: Hi, we're testing the newly released batch recovery and are running into class loading related issues. 1) We have a per-job flink cluster 2) We use BATCH execution mode + region failover strate

Re: [DISCUSS] Reducing build times

lts. If the community is generally interested in further investigating into that direction, I could look into software to orchestrate this, as well as sponsors for such an infrastructure. [1] https://docs.travis-ci.com/user/reference/overview/ On Fri, Aug 16, 2019 at 3:27 PM Chesnay Sche

[ANNOUNCE] Java 11 cron builds activated on master

Hello everyone, I just wanted to inform everyone that we now run Java 11 builds on Travis as part of the cron jobs, subsuming the existing Java 9 tests. All existing Java 9 build/test infrastructure has been removed. If you spot any test failures that appear to be specific to Java 11, please

Re: Is Flink documentation deployment script broken ?

The scripts are fine, but the buildbot slave is currently down. I've already opened a ticket with INFRA: https://issues.apache.org/jira/browse/INFRA-18986 On 06/09/2019 11:44, Jark Wu wrote: Hi all, I merged several documentation pull requests[1][2][3] days ago. AFAIK, the documentation depl

[DISCUSS] FLIP-67: Global partitions lifecycle

Hello, FLIP-36 (interactive programming) proposes a new programming paradigm where jobs are built incrementally by the user. To support this in an efficient manner I propose to extend part

Re: [Discussion] - Release major Flink version to support JDK 17 (LTS)

As it turns out Kryo isn't a blocker; we ran into a JDK bug. On 31/03/2023 08:57, Chesnay Schepler wrote: https://github.com/EsotericSoftware/kryo/wiki/Migration-to-v5#migration-guide Kroy themselves state that v5 likely can't read v2 data. However, both versions can be on the

Re: [DISCUSS] Planning Flink 2.0

This is definitely a good discussion so have. Some thoughts: One aspect that wasn't mentioned is what this release means going forward. I already waited a decade for 2.0; don't really want to wait another one to see Flink 3.0. We should discuss how regularly we will ship major releases from no

Re: [DISCUSS] Preventing Mockito usage for the new code with Checkstyle

The checkstyle rule would just ban certain imports. We'd add exclusions for all existing usages as we did when introducing other rules. So far we usually disabled checkstyle rules for a specific files. On 25/04/2023 16:34, Piotr Nowojski wrote: +1 to the idea. How would this checkstyle rule w

Re: [DISCUSS] Planning Flink 2.0

> /Instead of defining compatibility guarantees as "this API won't change in all 1.x/2.x series", what if we define it as "this API won't change in the next 2/3 years"./ I can see some benefits to this approach (all APIs having a fixed minimum lifetime) but it's just gonna be difficult to comm

Re: [DISCUSS] Preventing Mockito usage for the new code with Checkstyle

Best, Lijie Piotr Nowojski 于2023年4月25日周二 23:02写道： Ok, thanks for the clarification. Piotrek wt., 25 kwi 2023 o 16:38 Chesnay Schepler napisał(a): The checkstyle rule would just ban certain imports. We'd add exclusions for all existing usages as we did when introducing other rules. S

Re: [Discussion] - Release major Flink version to support JDK 17 (LTS)

> -- >> *From:* Jing Ge via user >> *Sent:* Monday, April 24, 2023 11:15 PM >> *To:* Chesnay Schepler >> *Cc:* Piotr Nowojski ; Alexis Sarda-Espinosa < >> sarda.espin...@gmail.com>; Martijn Visser

[NOTICE] Flink master branch now uses Maven 3.8.6

What happened? I have just merged the last commits to properly support Maven 3.3+ on the Flink master branch. mvnw and CI have been updated to use Maven 3.8.6. What does this mean for me? * You can now use Maven versions beyond 3.2.5 (duh). o Most versions should work, but

Re: [DISCUSS] FLIP-317: Upgrade Kryo from 2.24.0 to 5.5.0

The version in the state is the serializer version, and applies to the entire state, independent of what it contains. If you use Kryo2 for reading and Kryo5 for writing (which also implies writing the new serializer version into state), then I'd assume that a migration is an all-or-nothing kind

Re: [VOTE] Release flink-connector-jdbc v3.1.1, release candidate #1

I'm a bit concerned that the last 4 CI runs haven't succeeded in the 3.1 branch. Has anyone looked into the failing oracle test (both 1.17/1.18)? https://github.com/apache/flink-connector-jdbc/actions/runs/5058372107/jobs/9078398092 Why is a vote being opened when there's still a blocker ticket

Re: [DISCUSS] Status of Statefun Project

If you were to fork it /and want to redistribute it/ then the short version is that 1. you have to adhere to the Apache licensing requirements 2. you have to make it clear that your fork does not belong to the Apache Flink project. (Trademarks and all that) Neither should be significant hurd

Re: [DISCUSS] FLIP-317: Upgrade Kryo from 2.24.0 to 5.5.0

On 08/06/2023 16:06, Kurt Ostfeld wrote: If I understand correctly, the scenario is resuming from multiple checkpoint files or from a savepoint and checkpoint files which may be generated by different versions of Flink No; it's the same version of Flink, you just didn't do a full migration

Re: [DISCUSS] FLIP-321: Introduce an API deprecation process

On 13/06/2023 12:50, Jing Ge wrote: One major issue we have, afaiu, is caused by the lack of housekeeping/house cleaning, there are many APIs that were marked as deprecated a few years ago and still don't get removed. Some APIs should be easy to remove and others will need some more clear rules,

Re: [DISCUSS] FLIP-321: Introduce an API deprecation process

On 13/06/2023 17:26, Becket Qin wrote: It would be valuable if we can avoid releasing minor versions for previous major versions. On paper, /absolutely /agree, but I'm not sure how viable that is in practice. On the current 2.0 agenda is potentially dropping support for Java 8/11, which may

Re: [DISCUSS] FLIP-322 Cooldown period for adaptive scheduler

1) Options specific to the adaptive scheduler should start with "jobmanager.adaptive-scheduler". 2) There isn't /really /a notion of a "scaling event". The scheduler is informed about new/lost slots and job failures, and reacts accordingly by maybe rescaling the job. (sure, you can think of th

  1   2   3   4   5   6   7   8   9   10   >