lining created FLINK-14404:
--
Summary: the jvm heap size from calculateTaskManagerHeapSizeMB in
config.sh is different from TaskManagerServices.calculateHeapSizeMB
Key: FLINK-14404
URL: https://issues.apache.org/jira/bro
Hi Jark & Hequn,
Do you stick to introduce a looser FLIP? We possibly introduce a redundant
extra type
of community consensus if we are able to just reuse the process of current
FLIP. Given
the activity of our community I don't think it costs too much for a config
option keys
change with 3 days at
Hi all,
+1 to have a looser FLIP policy for these API changes.
I think the concerns raised above are all valid. Besides the feedbacks from
@Jark, if we want to keep track of these changes, maybe we can create a new
kind of FLIP that is dedicated to these minor API changes? For example, we
can add
Hi Xuefu,
Thank you for the feedback. I think you are pointing out a similar concern
with Bowen. Let me describe
how the catalog function and function factory will be changed in the
implementation section.
Then, we can have more discussion in detail.
Best Regards
Peter Huang
On Tue, Oct 15, 201
Hi Bowen,
Thanks for your kind feedback. This FLIP is to propose a function DDL
syntax that is compatible with all of the other related work.
I agree it is a little bit covering too many cases. From the perspective of
execution, I will mainly focus on the create and
persist a java class-based udf
Yun Tang created FLINK-14403:
Summary: Remove uesless NotifyCheckpointComplete and
TriggerCheckpoint
Key: FLINK-14403
URL: https://issues.apache.org/jira/browse/FLINK-14403
Project: Flink
Issue
Can anyone please help me with the conf files?
Am I missing anything on the configuration part?
Regards,
Pritam.
On Tue, 15 Oct 2019 at 08:48, Pritam Sadhukhan
wrote:
> Thanks for the information.
>
> I am able to see all the files using hdfs shell command.
> Even I am able to pull the data on
Hi all,
Recently Travis announced that ARM arch is in Alpha release[1]. Since Flink
has integrated with Travis already, I think it's quite easy for Flink to
use it for ARM CI.
Maybe some of you know that I'm working on Flink ARM testing and support. I
suggested to use OpenLab[2] as the ARM CI inf
vinoyang created FLINK-14402:
Summary:
KafkaProducerAtLeastOnceITCase>KafkaProducerTestBase.testOneToOneAtLeastOnceCustomOperator:214->KafkaProducerTestBase.testOneToOneAtLeastOnce
failed on Travis
Key: FLINK-14402
U
Thanks to Peter for the proposal!
I left some comments in the google doc. Besides what Bowen pointed out, I'm
unclear about how things work end to end from the document. For instance,
SQL DDL-like function definition is mentioned. I guess just having a DDL
for it doesn't explain how it's supporte
Bowen Li created FLINK-14401:
Summary: create DefaultCatalogFunctionFactory to instantiate
regular java class-based udf
Key: FLINK-14401
URL: https://issues.apache.org/jira/browse/FLINK-14401
Project: Fli
Definitely on the same page..+1 to keep it in a separate repo (at least
until the cose becomes "stable" and widely adopted from the community)
Il Mar 15 Ott 2019, 23:17 Stephan Ewen ha scritto:
> Hi Flink folks!
>
> After the positive reaction to the contribution proposal for Stateful
> Function
Hi Flink folks!
After the positive reaction to the contribution proposal for Stateful
Functions, I would like to kick off the discussion for the big question: In
which form should it go into Flink?
Before jumping into the "repository" question directly, let's get some
clarity on what would be our
+1
On Sun, Oct 13, 2019 at 10:54 PM Hequn Cheng wrote:
> +1
>
> Thanks a lot for driving this, Dian!
>
> On Mon, Oct 14, 2019 at 1:46 PM jincheng sun
> wrote:
>
> > +1
> >
> > Dian Fu 于2019年10月14日周一 下午1:21写道:
> >
> > > Hi all,
> > >
> > > I would like to start the vote for "Drop Python 2 suppo
Hi all,
I'd like to kick off a voting thread for FLIP-68: Extend Core Table System
with Pluggable Modules [1], as we have reached consensus in [2].
The voting period will be open for at least 72 hours, ending at 7pm Oct 18
UTC.
Thanks,
Bowen
[1]
https://cwiki.apache.org/confluence/display/FLINK
sorry, please ignore this thread as the FLIP's name should be "Extend Core
Table System with Pluggable Modules"
On Tue, Oct 15, 2019 at 9:59 AM Bowen Li wrote:
> Hi all,
>
> I'd like to kick off a voting thread for FLIP-68: Extend Core Table System
> with Modular Plugins [1], as we have reached
Hi Zhenqiu,
Thanks for taking on this effort!
A couple questions:
- Though this FLIP is about function DDL, can we also think about how the
created functions can be mapped to CatalogFunction and see if we need to
modify CatalogFunction interface? Syntax changes need to be backed by the
backend.
-
+1
On Tue, Oct 15, 2019 at 5:09 AM Jark Wu wrote:
> +1 from my side.
>
> Cheers,
> Jark
>
> On Tue, 15 Oct 2019 at 19:11, vino yang wrote:
>
> > +1
> >
> > Best,
> > Vino
> >
> > Aljoscha Krettek 于2019年10月15日周二 下午4:31写道:
> >
> > > +1
> > >
> > > Best,
> > > Aljoscha
> > >
> > > > On 14. Oct 20
Hi all,
I'd like to kick off a voting thread for FLIP-68: Extend Core Table System
with Modular Plugins [1], as we have reached consensus in [2].
The voting period will be open for at least 72 hours, ending at 5pm Oct 18,
UTC.
Thanks,
Bowen
[1]
https://cwiki.apache.org/confluence/display/FLINK/
Hi all,
I have updated the doc to reflect the discussion results. I will start a
voting thread shortly. Thanks!
Bowen
On Fri, Oct 11, 2019 at 12:44 AM Timo Walther wrote:
> I'm fine with `type` for consistency reasons for now. I hope we will fix
> that when we rework the properties design.
>
>
Hi all,
I hereby announce the FLIP has passed with 6 +1 votes, 4 binding (Dawid,
Timo, Aljoscha, Jark) and 2 non-binding (Xuefu, Jingsong).
Thanks for your review and participation!
On Thu, Oct 10, 2019 at 1:08 AM Jingsong Li wrote:
> +1
>
> Best,
> Jingsong Lee
>
> On Thu, Oct 10, 2019 at 3
Sorry for the confusion. I should have checked with an external mail
client. Thanks a lot for the clarification.
Cheers,
Till
On Tue, Oct 15, 2019 at 2:07 PM Jark Wu wrote:
> +1
>
> It is a separate [VOTE] thread in my Mail client.
>
> Best,
> Jark
>
> > 在 2019年10月15日,18:58,Dawid Wysakowicz 写道
Andrey Zagrebin created FLINK-14400:
---
Summary: Shrink the scope of MemoryManager from TaskExecutor to
slot
Key: FLINK-14400
URL: https://issues.apache.org/jira/browse/FLINK-14400
Project: Flink
Andrey Zagrebin created FLINK-14399:
---
Summary: Add memory chunk reservation API to MemoryManager
Key: FLINK-14399
URL: https://issues.apache.org/jira/browse/FLINK-14399
Project: Flink
Issue
Hao Dang created FLINK-14398:
Summary: Codegen produced larger-than-64kb method
Key: FLINK-14398
URL: https://issues.apache.org/jira/browse/FLINK-14398
Project: Flink
Issue Type: Bug
Co
Starting here the discussion after an initial discussion with Ververica and AWS
teams during FlinkForward.
I'm investigating the performances of a Flink job that transports data from
Kafka to an S3 Sink.
We are using a BucketingSink to write parquet files. The bucketing logic
divides the message
The naming concern above can be a separated issue since it looks also
affect FLIP-54 and isn't limited for config option changes FLIP.
Best,
tison.
Aljoscha Krettek 于2019年10月15日周二 下午8:37写道:
> Another PR that introduces new config options:
> https://github.com/apache/flink/pull/9759
>
> > On 15
Hi all,
This is an interesting problem and sometimes it bothers me too.
In general, I agree that it should deserve a voting process.
But I also share the same concern with Zili that the FLIP number will be
flooded.
So, I think the compromise way is such a small new interface does not need
a FLIP,
Another PR that introduces new config options:
https://github.com/apache/flink/pull/9759
> On 15. Oct 2019, at 14:31, Zili Chen wrote:
>
> Hi Aljoscha & Dawid & Kostas,
>
> I agree that changes on config option keys deserve a FLIP and it is
> reasonable
> we commit the changes with a standard
Rui Li created FLINK-14397:
--
Summary: Failed to run Hive UDTF with ClassCastException
Key: FLINK-14397
URL: https://issues.apache.org/jira/browse/FLINK-14397
Project: Flink
Issue Type: Bug
Hi Aljoscha & Dawid & Kostas,
I agree that changes on config option keys deserve a FLIP and it is
reasonable
we commit the changes with a standard FLIP process so that ensure the change
given proper visibility.
My concern is about naming. Given FLIP-73 as an example, if FLIPs
associated to
FLIP-7
Hi Aljoscha,
Given that config option keys are user-facing and any change there is
breaking, I think there should be a discussion about them and a FLIP,
where people have to actually vote for it seems to be the right place.
I understand that this is tedious (and actually I will also have to
open s
Hi Aljoscha,
I understand this might be troublesome at times, but I see benefit in
having at least 3 +1s from committers on those. In the end config
options are part of user facing API. In the end adapting config options
is a commitment to support those options in the future. I think having a
bett
+1 from my side.
Cheers,
Jark
On Tue, 15 Oct 2019 at 19:11, vino yang wrote:
> +1
>
> Best,
> Vino
>
> Aljoscha Krettek 于2019年10月15日周二 下午4:31写道:
>
> > +1
> >
> > Best,
> > Aljoscha
> >
> > > On 14. Oct 2019, at 14:55, Kurt Young wrote:
> > >
> > > +1
> > >
> > > Best,
> > > Kurt
> > >
> > >
>
+1
It is a separate [VOTE] thread in my Mail client.
Best,
Jark
> 在 2019年10月15日,18:58,Dawid Wysakowicz 写道:
>
> Hi Till,
>
> It should and it actually is.
>
> I think it's some feature of gmail that it groups conversations with a
> similar topic into a conversation. (I also see it this way i
Hi Everyone,
The title says it all, do you think we need to cover all config options that we
introduce/change by FLIPs? I was thinking about this because of the FLIP-73
work, which will introduce some new config options and also because I just
spotted a PR [1] that introduces some config option
zhijiang created FLINK-14396:
Summary: Implement rudimentary non-blocking network output
Key: FLINK-14396
URL: https://issues.apache.org/jira/browse/FLINK-14396
Project: Flink
Issue Type: Task
+1
Best,
Vino
Aljoscha Krettek 于2019年10月15日周二 下午4:31写道:
> +1
>
> Best,
> Aljoscha
>
> > On 14. Oct 2019, at 14:55, Kurt Young wrote:
> >
> > +1
> >
> > Best,
> > Kurt
> >
> >
> > On Fri, Oct 11, 2019 at 1:39 PM Dawid Wysakowicz >
> > wrote:
> >
> >> Hi everyone,
> >> I would like to start a v
+1 (non-binding)
Best,
Vino
Aljoscha Krettek 于2019年10月15日周二 下午2:59写道:
> +1 (binding)
>
> Best,
> Aljoscha
>
> > On 15. Oct 2019, at 04:01, Zili Chen wrote:
> >
> > Hi all,
> >
> > +1 from my side.
> >
> > Given the current state of this voting thread, FLIP-74 is accepted
> > with 3 binding vot
Hi Till,
It should and it actually is.
I think it's some feature of gmail that it groups conversations with a
similar topic into a conversation. (I also see it this way in gmail, but
I see it as separate threads in my mail client)
You can see that it is a separate thread e.g. in the ML archives:
I have updated the FLIP.
- adopted job-/cluster partitions naming scheme
- out-lined interface for new component living in the RM (currently
called ThinShuffleMaster, but I'm not a fan of the name. Suggestions
would be appreciated)
- added a note that the ShuffleService changes are only necessa
Shouldn't the voting happen in a distinct [VOTE] thread?
Cheers,
Till
On Tue, Oct 15, 2019 at 10:46 AM Kurt Young wrote:
> +1
>
> Best,
> Kurt
>
>
> On Tue, Oct 15, 2019 at 9:30 AM Dawid Wysakowicz
> wrote:
>
> > Hi everyone,
> > I would like to start a vote on FLIP-77.
> >
> > Please vote for
Hi Thomas,
Thanks a lot for your suggestion!
As you can see from the section "Goals" that this FLIP focuses on the
dependency management in process mode. However, the APIs and design proposed in
this FLIP also applies for the docker mode. So it makes sense to me to also
describe how this desig
+1
Best,
Kurt
On Tue, Oct 15, 2019 at 9:30 AM Dawid Wysakowicz
wrote:
> Hi everyone,
> I would like to start a vote on FLIP-77.
>
> Please vote for the following design document:
>
>
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-77%3A+Introduce+ConfigOptions+with+Data+Types
>
>
> Th
+1
Best,
Aljoscha
> On 14. Oct 2019, at 14:55, Kurt Young wrote:
>
> +1
>
> Best,
> Kurt
>
>
> On Fri, Oct 11, 2019 at 1:39 PM Dawid Wysakowicz
> wrote:
>
>> Hi everyone,
>> I would like to start a vote on FLIP-64. The discussion seems to have
>> reached an agreement.
>>
>> Please vote fo
+1 to Rong’s approach. We use a similar solution to the log context problem
on YARN setups. FYI.
WRT container contextual informations, we collection logs via ELK so that
the log file paths (which contains application id and container id) and the host
are attached with the logs. But if you don’t
vinoyang created FLINK-14395:
Summary: Refactor ES 6 connector to split table-specific code into
flink-sql-connector-elasticsearch6
Key: FLINK-14395
URL: https://issues.apache.org/jira/browse/FLINK-14395
Hi everyone,
I would like to start a vote on FLIP-77.
Please vote for the following design document:
https://cwiki.apache.org/confluence/display/FLINK/FLIP-77%3A+Introduce+ConfigOptions+with+Data+Types
The discussions can be found at:
https://lists.apache.org/thread.html/a56c6b52e5f828d4a7376
Good idea Aljosha, I will kick off a voting thread shortly as there were
no comments in this thread so far, so I would assume there are no
objections ;)
Best,
Dawid
On 15/10/2019 09:21, Aljoscha Krettek wrote:
> This looks very slim now! If there are no objections on this I would propose
> we q
This looks very slim now! If there are no objections on this I would propose we
quickly move on to a VOTE thread.
Best,
Aljoscha
> On 11. Oct 2019, at 10:35, Timo Walther wrote:
>
> Hi everyone,
>
> as mentioned in the [DISCUSS] thread of FLIP-54 [1]. The evolution of
> ConfigOption is a ver
50 matches
Mail list logo