Re: subscribe flink dev mail list

Hi, To subscribe to the dev mailing list you have to send an email to dev-subscr...@flink.apache.org Aljoscha > On 18. Jul 2019, at 10:58, venn wrote: > > I'am glad to subscribe the dev mail list >

Re: [DISCUSS] Support temporary tables in SQL API

I would be fine with option 3) but I think option 2) is the more implicit solution that has less surprising behaviour. Aljoscha > On 22. Jul 2019, at 23:59, Xuefu Zhang wrote: > > Thanks to Dawid for initiating the discussion. Overall, I agree with Timo > that for 1.9 we should have some quick

Re: [DISCUSS] Support temporary tables in SQL API

lso try to >> reuse the in-memory catalog >> for the builtin temporary table storage. >> >> Regarding to option #2 and option #3, from user's perspective, IIUC option >> #2 allows user to have >> simple name to reference temporary table and should use fully qua

Re: [DISCUSS] Support temporary tables in SQL API

opriate PRs according to the decision (unless somebody > objects). We will revisit the long-term solution in a separate thread as part > of the 1.10 release after 1.9 is released. > > Thank you all for your opinions! > > Best, > > Dawid > > On 24/07/2019 09:35, A

Re: flink-mapr-fs failed in travis

I’m seeing the same issue when building this locally. I’ll start a DISCUSS thread so see about just removing the flink-mapr-fs module. Aljoscha > On 24. Jul 2019, at 05:00, JingsongLee > wrote: > > Sorry, > "It looks like it's been compiled all the time." > should be: "It looks like it can

[DISCUSS] Removing the flink-mapr-fs module

Hi, Because of recent problems in the dependencies of that module [1] I would suggest that we remove it. If people are using it, they can use the one from Flink 1.8. What do you think about it? It would a) solve the dependency problem and b) make our build a tiny smidgen more lightweight. Alj

Re: [DISCUSS] Removing the flink-mapr-fs module

l 29, 2019 at 5:19 PM Ufuk Celebi wrote: > >> +1 >> >> >> On Mon, Jul 29, 2019 at 11:06 AM Jeff Zhang wrote: >> >>> +1 to remove it. >>> >>> Aljoscha Krettek 于2019年7月29日周一 下午5:01写道： >>> >>>> Hi, >>>>

Re: [DISCUSS] Removing the flink-mapr-fs module

-- > From:Biao Liu > Send Time:2019年7月29日(星期一) 12:05 > To:dev > Subject:Re: [DISCUSS] Removing the flink-mapr-fs module > > +1 for removing it. > > Actually I encountered this issue several times. I thought it might be > blocked by firewall of China :( >

Re: [DISCUSS][CODE STYLE] Usage of Java Optional

Hi, I’m also in favour of using Optional only for method return values. I could be persuaded to allow them for parameters of internal methods but I’m sceptical about that. Aljoscha > On 2. Aug 2019, at 15:35, Yu Li wrote: > > TL; DR: I second Timo that we should use Optional only as method r

Re: [VOTE] Publish the PyFlink into PyPI

+1 (binding) > On 1. Aug 2019, at 17:23, Hequn Cheng wrote: > > +1 (non-binding) > > Thanks a lot for driving this! @jincheng sun > > Best, Hequn > > On Thu, Aug 1, 2019 at 11:00 PM Biao Liu wrote: > >> Thanks Jincheng for working on this. >> >> +1 (non-binding) >> >> Thanks, >> Biao /'b

Re: [VOTE] Flink Project Bylaws

+1 > On 11. Aug 2019, at 10:07, Becket Qin wrote: > > Hi all, > > I would like to start a voting thread on the project bylaws of Flink. It > aims to help the community coordinate more smoothly. Please see the bylaws > wiki page below for details. > > https://cwiki.apache.org/confluence/pages/v

Re: [DISCUSS] Drop stale class Program

Hi, I would be in favour of removing Program (and the code paths that support it) for Flink 1.10. Most users of Flink don’t actually know it exists and it is only making our code more complicated. Going forward with the new Client API discussions will be a lot easier without it as well. Best,

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

+1 I did some testing on a Google Cloud Dataproc cluster (it gives you a managed YARN and Google Cloud Storage (GCS)): - tried both YARN session mode and YARN per-job mode, also using bin/flink list/cancel/etc. against a YARN session cluster - ran examples that write to GCS, both with the na

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

+1 (for the same reasons I posted on the other thread) > On 14. Aug 2019, at 15:03, Zili Chen wrote: > > +1 > > It could be regarded as part of Flink client api refactor. > Removal of stale code paths helps reason refactor. > > There is one thing worth attention that in this thread[1] Thomas >

Re: [VOTE] FLIP-51: Rework of the Expression Design

+1 This seems to be a good refactoring/cleanup step to me! > On 16. Aug 2019, at 10:59, Dawid Wysakowicz wrote: > > +1 from my side > > Best, > > Dawid > > On 16/08/2019 10:31, Jark Wu wrote: >> +1 from my side. >> >> Thanks Jingsong for driving this. >> >> Best, >> Jark >> >> On Thu, 15

Re: [DISCUSS] Reducing build times

Speaking of flink-shaded, do we have any idea what the impact of shading is on the build time? We could get rid of shading completely in the Flink main repository by moving everything that we shade to flink-shaded. Aljoscha > On 16. Aug 2019, at 14:58, Bowen Li wrote: > > +1 to Till's points

Re: [DISCUSS] Flink client api enhancement for downstream project

;>>> >>>>>>>>> 1) CliFrontend should exactly be a front end, at least for >>> "run" >>>>>>> command. >>>>>>>>> That means it just gathered and passed all config from >> command >>>> line >>&

Re: [DISCUSS] Reducing build times

any tests, API >> compatibility checks, checkstyle, layered shading (e.g., flink-runtime >> and flink-dist, where both relocate dependencies and one is bundled by >> the other), and, most importantly, CI (and really, without CI being >> covered in a PoC there's nothing

Flink 1.7 Development Priorities

Hi Everyone, After the recent Flink 1.6 release the people working on Flink at data Artisans came together to talk about what we want to work on for Flink 1.7. The following is a list of high-level directions that we will be working on for the next couple of months. This doesn't mean that other

Re: Flink cluster crashing going from 1.4.0 -> 1.5.3

Hi, So with Flink 1.5.3 but a smaller parallelism the job works fine? Best, Aljoscha > On 23. Aug 2018, at 15:25, Jozef Vilcek wrote: > > Hello, > > I am trying to get my Beam application (run on newer version of Flink > (1.5.3) but having trouble with that. When I submit application, everyth

Re: Please review : Re: PubSub connector (FLINK-9311)

Hi Niels and Richard, I would be very happy about having a PubSub connector in Flink. Having it in Flink means that you don't have manual effort for tracking API changes and I think having a production user is incentive enough for them (you) to maintain the connector. I'm afraid we don't have

Re: [DISCUSS] [Contributing] (3) - Review Tooling

In Beam, we have a bot that regularly nags people about inactive PRs and also closes them after long inactivity. And we use the github feature for assigning reviewers in github. Sometimes it is hard for people to judge how "valuable" a PR is. Maybe some knowledgable people could mark PRs as val

Re: [DISCUSS] Improvements to the Unified SQL Connector API

Thanks for the proposal! I like the proposed changes a lot, especially support for reading/writing key data of systems that have a key/value split will be very nice to have. > On 2. Oct 2018, at 11:58, Timo Walther wrote: > > Thanks for the feedback Fabian. I updated the document and addressed

Re: [DISCUSS] Dropping flink-storm?

+1 for dropping it > On 1. Oct 2018, at 10:55, Fabian Hueske wrote: > > +1 to drop it. > > Thanks, Fabian > > Am Sa., 29. Sep. 2018 um 12:05 Uhr schrieb Niels Basjes : > >> I would drop it. >> >> Niels Basjes >> >> On Sat, 29 Sep 2018, 10:38 Kostas Kloudas, >> wrote: >> >>> +1 to drop it

[DISCUSS] Breaking the Scala API for Scala 2.12 Support

Hi, I'm currently working on https://issues.apache.org/jira/browse/FLINK-7811, with the goal of adding support for Scala 2.12. There is a bit of a hurdle and I have to explain some context first. With Scala 2.12, lambdas are implemented using the lambda mechanism of Java 8, i.e. Scala lambdas

Re: [DISCUSS] Breaking the Scala API for Scala 2.12 Support

>> Cheers, >> Till >> >> On Thu, Oct 4, 2018 at 7:36 PM Elias Levy >> wrote: >> >>> The second alternative, with the addition of methods that take functions >>> with Scala types, seems the most sensible. I wonder if there is a need >>>

Re: [DISCUSS] Breaking the Scala API for Scala 2.12 Support

8.10.2018 12:24, Aljoscha Krettek wrote: >> I have an open PR that does everything we can do for preparing the code base >> for Scala 2.12 without breaking the API: >> https://github.com/apache/flink/pull/6784 >> >>> On 8. Oct 2018, at 09:56, Chesnay Schepler

Re: [DISCUSS] Breaking the Scala API for Scala 2.12 Support

> On 08.10.2018 15:04, Aljoscha Krettek wrote: >> Breaking the API (or not breaking it but requiring explicit types when using >> Scala 2.12) and the Maven infrastructure to actually build a 2.12 release. >> >>> On 8. Oct 2018, at 13:00, Chesnay Schepler wrote: &g

Re: Sharing state between subtasks

Yes, I think this is the way to go. This would also go well with a redesign of the source interface that has been floated for a while now. I also created a prototype a while back: https://github.com/aljoscha/flink/tree/refactor-source-interface

Re: Sharing state between subtasks

is consensus on the best >> way forward maybe we should be looking at introducing the time-alignment >> properly instead of hacking the sources. >> >> >> >> >> On Tue, Oct 9, 2018 at 12:01 PM Elias Levy >> wrote: >> >>> On Tue, Oct

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

+1 I did - verify all changes between 4.0 and 5.0 - check signature and hash of the source release - build a work-in-progress branch for Scala 2.12 support using the new shaded asm6 package > On 10. Oct 2018, at 15:11, Chesnay Schepler wrote: > > Hi everyone, > Please review and vote on the

Re: [DISCUSS] [Contributing] (2) - Review Steps

+1 > On 9. Oct 2018, at 17:11, Hequn Cheng wrote: > > +1 > > On Tue, Oct 9, 2018 at 3:25 PM Till Rohrmann wrote: > >> +1 >> >> On Tue, Oct 9, 2018 at 9:08 AM Zhijiang(wangzhijiang999) >> wrote: >> >>> +1 >>> -- >>> 发件人：vino ya

Re: Sharing state between subtasks

The reason this selective reading doesn't work well in Flink in the moment is because of checkpointing. For checkpointing, checkpoint barriers travel within the streams. If we selectively read from inputs based on timestamps this is akin to blocking an input if that input is very far ahead in ev

Re: [DISCUSS] Release 1.5.5 and 1.6.2

Hi, I think the "savepoints for recovery" change is a fix for likely violation of exactly-once guarantees while it has close to zero downsides in real-world use cases. Therefore I think we should not revert it and release the fix for 1.5.5 and 1.6.2. Best, Aljoscha > On 16. Oct 2018, at 13:48

Re: Sharing state between subtasks

source level it should be perfectly fine to do what Elias >> proposed. This is of course is not the perfect solution but could bring us >> forward quite a bit. The changes required for this should also be minimal. >> This would become obsolete once we have something like shared state.

Re: [DISCUSS] Breaking the Scala API for Scala 2.12 Support

using Scala 2.11 > On 26. Oct 2018, at 11:06, Chesnay Schepler wrote: > > I was wondering about the outcome of this discussion on what it means for our > users. > > In particular: Does this API break only apply to 2.12 users, or also for > people using 2.11? > > On 04

Re: [DISCUSS] Breaking the Scala API for Scala 2.12 Support

, Long)]) => { val prevPaths = prev.toSet for (n <- next) if (!prevPaths.contains(n)) out.collect(n) } } The only required changes will be explicit type annotations in lambdas. There is no casting or other "hacky" stuff required. > On 30. Oct 2018, at 11:43, Aljosc

[DISCUSS] FLIP-27: Refactor Source Interface

Hi All, In order to finally get the ball rolling on the new source interface that we have discussed for so long I finally created a FLIP: https://cwiki.apache.org/confluence/display/FLINK/FLIP-27%3A+Refactor+Source+Interface I cc'ed Thomas and Jamie because of the ongoing work/discussion about

Re: [DISCUSS] Enhancing the functionality and productivity of Table API

Hi Jincheng, these points sound very good! Are there any concrete proposals for changes? For example a FLIP/design document? See here for FLIPs: https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals Best, Aljoscha > On 1. Nov 2018, at 12:51, jincheng sun wrote: > >

Re: [DISCUSS] Enhancing the functionality and productivity of Table API

the community's views on Enhancing the > functionality and productivity of Table API, to ensure that it worth to > effort. If most community members agree with my proposal, I will list the > changes and discuss with all community members. Is that make sense to you? > > Thanks, &g

Re: [DISCUSS] FLIP-27: Refactor Source Interface

ElementWithTimestamp` because some >>>>> sources want to add timestamp to every element. IMO, this is not so >>> memory >>>>> friendly so I prefer this design. >>>>> >>>>> >>>>> >>>>> Thanks >&

Re: [VOTE] Release 1.7.0, release candidate #1

I looked into this issue and my conclusion was that test-jars don't pull in transitive dependencies when you depend on them. I verified this with an example maven project where I also verified that a test-jar built with Scala 2.12 works on a project that uses Scala 2.11. On the hcatalog connect

Re: StreamingFileSink Bug? Committing results on stream close

Hi Addison, unfortunately, there is a long-standing problem that user functions cannot differentiate between successful and erroneous shutdown [1]. I had this high on my private list of things that I finally want to see fixed in Flink 1.8. And your message further confirms this. Best, Aljoscha

Re: [DISCUSS] FLIP-27: Refactor Source Interface

alling thread will perform a >> bunch >>>>>>>> of >>>>>>>>> IO asynchronously. >>>>>>>>> - When take() is called, the same calling thread will perform a >>>>>>>> bunch >>>>&

Re: [DISCUSS] Unified Core API for Streaming and Batch

Hi All, this is a great discussion! (I have some thoughts on most of the topics but I'll wait for the separate discussion threads) @Haibo Will you start a separate threads? I think the separate discussion topics would be (based on Stephans mail but further split up): 1. What should the API sta

Re: [DISCUSS] Long-term goal of making flink-table Scala-free

Hi, this is a very nice effort! There is one thing that we should change, though. In the batch API we have a clear separation between API and runtime, and using the API (depending on flink-batch) does not "expose" the runtime classes that are in flink-runtime. For the streaming API, we made th

Re: [VOTE] Release 1.6.3, release candidate #1

+1 - signatures/hashes are ok - verified that the log contains no suspicious output when running a local cluster > On 18. Dec 2018, at 14:31, Chesnay Schepler wrote: > > +1 > > - signatures ok > - src contains no binaries > - binary not missing any jars > - tag exists > - release notes classi

Re: [VOTE] Release 1.5.6, release candidate #1

+1 - signatures/hashes are ok - manually checked the logs after running an example on a local cluster There is this exception in the client log when running without Hadoop in the classpath: 2018-12-19 18:34:54,876 WARN org.apache.flink.client.cli.CliFrontend - Could not

Re: [NOTICE] Mandatory migration of git repositories to gitbox.apache.org

Sounds good. > On 3. Jan 2019, at 14:27, Chesnay Schepler wrote: > > Since neither of these repositories are in use (flink-libraries is empty, and > incubator-flink is 3+ years old) we could just drop them I suppose. > > Any objections? > > On 03.01.2019 14:18, Apache Infrastructure Team wrot

[DISCUSS] Bot for stale PRs on GitHub

Hi, I know we had similar discussions in the past but I’d like to bring up this topic again. What do you think about adding a stale bot (https://probot.github.io/apps/stale/ ) to our Github Repo? This would automatically nag about stale PRs and close them

Re: [DISCUSS] Bot for stale PRs on GitHub

me PRs that I had open at Beam Aljoscha > On 10. Jan 2019, at 11:21, Chesnay Schepler wrote: > > Without any new argument for doing so, I'm still against it. > > On 10.01.2019 09:54, Aljoscha Krettek wrote: >> Hi, >> >> I know we had similar discussio

Re: [DISCUSS] Bot for stale PRs on GitHub

I think the automatic closing is an integral part, without it we would never close those stale PRs that we have lying around from 2015 and 2016. I would suggest to set the staleness interval quite high, say 2 months. Thus initially the bot would mainly close very old PRs and we shouldn’t even no

Re: [DISCUSS] Bot for stale PRs on GitHub

bly update the contribution >>> guide as a means of preventing such PRs from being opened again. This >>> also provides committers with a reference based on which they can >>> close future PRs. >>> >>> Recommending contributors to continuously update their P

Re: [DISCUSS] Start new Review Process

What do you mean by “merging cannot happen through the GitHub user interface”? You can in fact merge PRs by clicking on the merge button, or “rebase and merge”. Aljoscha > On 29. Jan 2019, at 11:58, Robert Metzger wrote: > > @Fabian: Thank you for your suggestions. Multiple approvals in one c

[DISCUSS] Releasing Flink 1.8 / Feature Freeze

Hi All, In reference to a recent mail by Ufuk [1] and because it has been a while since the last Flink release we should start thinking about a Flink 1.8 release. We’re actually a bit behind the cadence but I think we still shouldn’t rush things. I’m hereby proposing myself as release manager f

Re: [DISCUSS] Enhance Operator API to Support Dynamically Selective Reading and EndOfInput Event

While we’re on operators and tasks, I think it would also make sense in the long run to move the logic that is now in AbstractStreamOperator.setup()/initializeState()/snapshot()/snapshotState()(and the other snapshotState()…)/dispose() outside of the operator itself. This logic is the same for

Re: List of consumed kafka topics should not be restored from state

I think these two Jira issues are relevant here: - https://issues.apache.org/jira/browse/FLINK-10342 - https://issues.apache.org/jira/browse/FLINK-9303 The second one only because it’s slight

Re: [VOTE] Release Apache Flink 1.7.2, release candidate #1

+1 - verified signatures and hashes - started cluster for both Scala 2.11 and 2.12, ran examples, verified web ui and log output (there is an exception in the log when running without Hadoop, should fix that but not a blocker) - manually verified the diff pom files between 1.7.1 and 1.7.2 to che

[ANNOUNCE] Flink 1.8 release branch has been cut

Hi Everyone, I just created the branch for the Flink 1.8 release [1] and updated the version on master to 1.9-SNAPSHOT. Apparently we already had a 1.9.0 version in our jira [2]. I’ll create a first release candidate shortly, stay tuned! Best, Aljoscha [1] https://gitbox.apache.org/repos/asf

Re: Flaky tests

I agree with Chesnay, and I would like to add that the most important step towards fixing flakiness is awareness and willingness. As soon as you accept flakiness and start working around it (as you mentioned) more flakiness will creep in, making it harder to get rid of it in the future. Aljosch

[ANNOUNCE] Update on Flink 1.8 Release Progress

Hi Everyone, We are now about a week after cutting the release-1.8 branch and things are looking quite good! The community has worked hard on fixing bugs and test instabilities. There are now only two issues that are marked as “blocker” in our Jira: [1]. The first of which is about updating the

Re: [DISCUSS] Introducing Builder in FlinkKafkaProducer

I think before doing anything quick here we should look at this more holistically: How do the different connectors work, i.e. how do you construct them? Can we find a way to unify that, maybe using a Builder pattern? And then should we make a plan of getting the connectors there, possibly with a

[DISCUSS] Using Guava in Flink "core" packages

Hi, I recently saw that we added a dependency on our shaded-guava to flink-core [1]. Just for the record, I don’t want do diminish the contributions of anyone involved in the PR in any way. It just made me realise that we have some implicit agreements or assumptions about adding certain things

Re: [DISCUSS] Using Guava in Flink "core" packages

>> user-facing class. >> If this is to be used by connectors, which are included in the user-jar, >> then we're violating the principle above, in which case the class should >> be relocated/removed. >> >> On 06.03.2019 15:10, Aljoscha Krettek wrote: >>&

Re: [ANNOUNCE] Update on Flink 1.8 Release Progress

browse/FLINK-11501> > > Thanks, > Thomas > > > On Fri, Mar 1, 2019 at 7:43 AM Aljoscha Krettek <mailto:aljos...@apache.org>> wrote: > >> Hi Everyone, >> >> We are now about a week after cutting the release-1.8 branch and things >> are lookin

[VOTE] Release 1.8.0, release candidate #1

Hi everyone, Please review and vote on the release candidate 1 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 o

Re: [DISCUSS] FLIP-33: Terminate/Suspend Job with Savepoint

I agree and already created a Jira issue for removing the old “stop” feature as preparation: https://issues.apache.org/jira/browse/FLINK-11889 Aljoscha > On 7. Mar 2019, at 11:08, Kostas Kloudas wrote: > > Hi, > > Thanks for the comments. >

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

inaries >>>>> - checked that all POM files point to the same version >>>>> - build from source >>>>> >>>>> Best, >>>>> Kurt >>>>> >>>>> >>>>> On Tue, Mar 12, 2019 at 9:20 AM

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

Hi, I’m hereby canceling the vote for RC1 of Flink 1.8.0 because of the aforementioned issues. I’ll create a new RC as soon as those issues are resolved. Best, Aljoscha > On 13. Mar 2019, at 12:24, Aljoscha Krettek wrote: > > Hi, > > Thanks for the verification performed so

Re: [CANCEL][VOTE] Release 1.8.0, release candidate #1

. >> Looking forward to the new RC. >> >> Best, >> Jincheng >> >> Aljoscha Krettek 于2019年3月13日周三 下午7:25写道： >> >>> Hi, >>> >>> I’m hereby canceling the vote for RC1 of Flink 1.8.0 because of the >>> aforementioned issues

[VOTE] Release 1.8.0, release candidate #2

Hi everyone, Please review and vote on the release candidate 2 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 off

[REMINDER] Please add entries for newly added dependencies to NOTICE file

Hi All, Please remember to add newly added dependencies to the NOTICE file of flink-dist (which will then end up in NOTICE-binary and so on). Discovering this late will cause delays in releases, as it is doing now. There is a handy guide that Chesnay and Till worked on that explains licensing

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

nges for >>>> `downloads.html#optional-components`, add the Hadoop relation JARs >>> download >>>> link first. >>>> 2. Then add instructions on how to get the dependencies of the >>> Hadoop or >>>> add the correct download link directly

Re: [REMINDER] Please add entries for newly added dependencies to NOTICE file

d a conditional check for this into flink-bot in case a pom.xml was > modified. Otherwise it will be easy to forget in the future. > > – Ufuk > > On Mon, Mar 18, 2019 at 12:03 PM Aljoscha Krettek wrote: >> >> Hi All, >> >> Please remember to add newly added d

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

>>>> for the >>>>>>> time being. However, the result seems to be unstable. I also tried >>>> the >>>>>>> benchmark locally and observed obvious wave even with the same >>>>> commit... >>>>>>> &

[VOTE] Release 1.8.0, release candidate #3

Hi everyone, Please review and vote on the release candidate 3 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 off

[DISCUSS] Reorganizing Table-related Jira components some more

Hi, First of all, I hope I cc’ed all the relevant people. Sorry if I forgot anyone. I would like to restructure the Table/SQL-related Jira components a bit more to better reflect the current state of components. Right now we have: * API / Table SQL: this is just a wild collection of table-relat

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

e user thread and not the dev thread anymore. Let’s see what we do next time. > On 21. Mar 2019, at 14:15, Aljoscha Krettek wrote: > > Hi Yu, > > I commented on the issue. For me both Hadoop 2.8.3 and Hadoop 2.4.1 seem to > work. Could you have a look at my comment? > &

Re: [DISCUSS] Reorganizing Table-related Jira components some more

he "classic planner" and "new planner", the > naming will be inaccurate after blink merge done and we deprecated classic > planner later (if it happens). > If only one planner left, then what component should we use when creating > jira? > > How about this: >

[VOTE] Release 1.8.0, release candidate #4

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 off

Re: [DISCUSS] Reorganizing Table-related Jira components some more

gt;> Table SQL / Runtime >>> Table SQL / Ecosystem (such as table connectors, formats, Hive catalog >>> etc.) >>> >>> This should make everyone happy, no? >>> >>> Thanks for proosing this Aljoscha. Big +1. >>> >>> Regards, >&g

Re: [DISCUSS] Using Guava in Flink "core" packages

> On Wed, Mar 6, 2019 at 7:13 AM Thomas Weise wrote: > >> How I managed to do that.. >> >> Here is the discussion about the shared package: >> >> >> https://lists.apache.org/thread.html/3de9d2353cf22aea0448fb744314103b5f88195216acc3bff449354a@%3Cdev.f

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

error messages should be encountered > > 4. Review the PR > - [Add 1.8 Release Blog Post] - Just a reminder, updated the release > date to correct date before merging. > > Cheers, > Jincheng > > Piotr Nowojski 于2019年3月25日周一 下午4:11写道： > >> +1 from my side.

Re: [DISCUSS] have separate Flink distributions with built-in Hive dependencies

I was going to suggest the same thing as Seth. So yes, I’m against having Flink distributions that contain Hive but for convenience downloads as we have for Hadoop. Best, Aljoscha > On 13. Dec 2019, at 18:04, Seth Wiesman wrote: > > I'm also -1 on separate builds. > > What about publishing c

Re: [DISCUSS] Drop vendor specific repositories from pom.xml

+1 to remove > On 20. Dec 2019, at 10:34, Robert Metzger wrote: > > Okay, I understand. I'm okay with removing the profile. > > On Thu, Dec 19, 2019 at 11:34 AM Till Rohrmann wrote: > >> The profiles make bumping ZooKeeper's version a bit more cumbersome. I >> would be interested for this rea

Re: [DISCUSS] Make AppendingState#add refuse to add null element

Hi, As I said in the discussion on the Jira issue, I’m in favour of this change! This is the Jira Issue, for reference: https://issues.apache.org/jira/browse/FLINK-15424 Best, Aljoscha > On 8. Jan 2020, at 15:16, Congxian Qiu wrote: > > Dear All > > > Currently, we found the implementation

Re: [DISCUSS] Make AppendingState#add refuse to add null element

ther this is by design, @Aljoscha Krettek<mailto:aljos...@apache.org> would you please share the initial idea when introducing this for the first time? [1] https://ci.apache.org/projects/flink/flink-docs-stable/dev/stream/operators/windows.html#reducefu

Re: [VOTE] FLIP-92: Add N-Ary Stream Operator in Flink

+1 I approve this FLIP. Best, Aljoscha On 20.01.20 15:24, Piotr Nowojski wrote: Thank you all for the votes. So far we have received 7 approving votes, 2 of which are binding and there is no -1 votes: * Nico (binding) * Zhijiang (binding) * Zhenghua (non-binding) * Yun (non-binding) * Haibo

Caveats of multi-execute() Flink programs

now think that the "execute-style" of writing jobs does not work well for streaming programs and we might have to re-introduce an interface like interface FlinkJob { Pipeline getPipeline(); } for streaming scenarios. Kostas: I have to think about the whole issue more, but definitel

Re: Caveats of multi-execute() Flink programs

round specifying a savepoint on the CLI. Passing multiple savepoints to individual environments would be necessary but I don't know what would be a good solution. To me, it feels like multi-execute() only makes sense for batch programs. Best, Aljoscha On 23.01.20 17:03, Aljoscha Krettek wrote:

Re: [VOTE] Release 1.10.0, release candidate #1

+1 (binding) - I verified the checksum - I verified the signatures - I eyeballed the diff in pom files between 1.9 and 1.10 and checked any newly added dependencies. They are ok. If the 1.9 licensing was correct the licensing on this should also be correct - I manually installed Flink Python an

Re: [DISCUSS] Upload the Flink Python API 1.9.x to PyPI for user convenience.

Hi, I think that's a good idea, but we will also soon have Flink 1.10 anyways. Best, Aljoscha On 04.02.20 07:25, Hequn Cheng wrote: Hi Jincheng, +1 for this proposal. From the perspective of users, I think it would nice to have PyFlink on PyPI which makes it much easier to install PyFlink.

Re: [DISCUSS] Upload the Flink Python API 1.9.x to PyPI for user convenience.

have already prepared the package), personally I think it worths to do that. What's your thought? :) Best, Jincheng Aljoscha Krettek 于2020年2月4日周二 下午4:00写道： Hi, I think that's a good idea, but we will also soon have Flink 1.10 anyways. Best, Aljoscha On 04.02.20 07:25, Hequn C

Re: [DISCUSS] Does removing deprecated interfaces needs another FLIP

I would say a ML discussion or even a Jira issue is enough because a) the methods are already deprecated b) the methods are @PublicEvolving, which I don't consider a super strong guarantee to users (we still shouldn't remove them lightly, but we can if we have to...) Best, Aljoscha On 07.02.

Re: [Discussion] Job generation / submission hooks & Atlas integration

If we need it, we can probably beef up the JobListener to allow accessing some information about the whole graph or sources and sinks. My only concern right now is that we don't have a stable interface for our job graphs/pipelines right now. Best, Aljoscha On 06.02.20 23:00, Gyula Fóra wrote:

Re: [DISCUSS] Drop connectors for Elasticsearch 2.x and 5.x

+1 for dropping them, this stuff is quite old by now. On 10.02.20 15:04, Benchao Li wrote: +1 for dropping 2.x - 5.x. FYI currently only 6.x and 7.x ES Connectors are supported by table api. Flavio Pompermaier 于2020年2月10日周一 下午10:03写道： +1 for dropping all Elasticsearch connectors < 6.x On M

Re: [VOTE] FLIP-55: Introduction of a Table API Java Expression DSL

+1 Best, Aljoscha On 11.02.20 11:17, Jingsong Li wrote: Thanks Dawid for your explanation, +1 for vote. So I am big +1 to accepting java.lang.Object in the Java DSL, without scala implicit conversion, a lot of "lit" look unfriendly to users. Best, Jingsong Lee On Tue, Feb 11, 2020 at 6:07 P

Re: [Discussion] Job generation / submission hooks & Atlas integration

gs. The Atlas hook works on this map. This is very fragile and depends on a lot of internals. Kind of like exposing the JobGraph but much worse. I think we can do better. Gyula On Fri, Feb 7, 2020 at 9:55 AM Aljoscha Krettek wrote: If we need it, we can probably beef up the JobListener to al

Re: [DISCUSS] Improve history server with log support

Hi, what's the difference in approach to the mentioned related Jira Issue ([1])? I commented there because I'm skeptical about adding Hadoop-specific code to the generic cluster components. Best, Aljoscha [1] https://issues.apache.org/jira/browse/FLINK-14317 On 13.02.20 03:47, SHI Xiaogang

[ANNOUNCE] New Documentation Style Guide

Hi Everyone, we just merged a new style guide for documentation writing: https://flink.apache.org/contributing/docs-style.html. Anyone who is writing documentation or is planning to do so should check this out. Please open a Jira Issue or respond here if you have any comments or questions.

<    1   2   3   4   5   6   7   8   9   10   >