Re: [VOTE] Accept Flink CDC into Apache Flink

[Jing Ge]

+1 (not binding)

Best regards,
Jing

On Tue, Jan 9, 2024 at 8:46 AM Xintong Song  wrote:

> +1 (binding)
>
> Best,
>
> Xintong
>
>
>
> On Tue, Jan 9, 2024 at 3:31 PM Benchao Li  wrote:
>
> > +1 (non-binding)
> >
> > Feng Wang  于2024年1月9日周二 15:29写道：
> > >
> > > +1 non-binding
> > > Regards,
> > > Feng
> > >
> > > On Tue, Jan 9, 2024 at 3:05 PM Leonard Xu  wrote:
> > >
> > > > Hello all,
> > > >
> > > > This is the official vote whether to accept the Flink CDC code
> > contribution
> > > >  to Apache Flink.
> > > >
> > > > The current Flink CDC code, documentation, and website can be
> > > > found here:
> > > > code: https://github.com/ververica/flink-cdc-connectors <
> > > > https://github.com/ververica/flink-cdc-connectors>
> > > > docs: https://ververica.github.io/flink-cdc-connectors/ <
> > > > https://ververica.github.io/flink-cdc-connectors/>
> > > >
> > > > This vote should capture whether the Apache Flink community is
> > interested
> > > > in accepting, maintaining, and evolving Flink CDC.
> > > >
> > > > Regarding my original proposal[1] in the dev mailing list, I firmly
> > believe
> > > > that this initiative aligns perfectly with Flink. For the Flink
> > community,
> > > > it represents an opportunity to bolster Flink's competitive edge in
> > > > streaming
> > > > data integration, fostering the robust growth and prosperity of the
> > Apache
> > > > Flink
> > > > ecosystem. For the Flink CDC project, becoming a sub-project of
> Apache
> > > > Flink
> > > > means becoming an integral part of a neutral open-source community,
> > > > capable of
> > > > attracting a more diverse pool of contributors.
> > > >
> > > > All Flink CDC maintainers are dedicated to continuously contributing
> to
> > > > achieve
> > > > seamless integration with Flink. Additionally, PMC members like Jark,
> > > > Qingsheng,
> > > > and I are willing to infacilitate the expansion of contributors and
> > > > committers to
> > > > effectively maintain this new sub-project.
> > > >
> > > > This is a "Adoption of a new Codebase" vote as per the Flink bylaws
> > [2].
> > > > Only PMC votes are binding. The vote will be open at least 7 days
> > > > (excluding weekends), meaning until Thursday January 18 12:00 UTC, or
> > > > until we
> > > > achieve the 2/3rd majority. We will follow the instructions in the
> > Flink
> > > > Bylaws
> > > > in the case of insufficient active binding voters:
> > > >
> > > > > 1. Wait until the minimum length of the voting passes.
> > > > > 2. Publicly reach out via personal email to the remaining binding
> > voters
> > > > in the
> > > > voting mail thread for at least 2 attempts with at least 7 days
> between
> > > > two attempts.
> > > > > 3. If the binding voter being contacted still failed to respond
> after
> > > > all the attempts,
> > > > the binding voter will be considered as inactive for the purpose of
> > this
> > > > particular voting.
> > > >
> > > > Welcome voting !
> > > >
> > > > Best,
> > > > Leonard
> > > > [1] https://lists.apache.org/thread/o7klnbsotmmql999bnwmdgo56b6kxx9l
> > > > [2]
> > > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
> >
> >
> >
> > --
> >
> > Best,
> > Benchao Li
> >
>

[jira] [Created] (FLINK-34038) IncrementalGroupAggregateRestoreTest.testRestore fails

[Matthias Pohl (Jira)]

Matthias Pohl created FLINK-34038:
-

 Summary: IncrementalGroupAggregateRestoreTest.testRestore fails
 Key: FLINK-34038
 URL: https://issues.apache.org/jira/browse/FLINK-34038
 Project: Flink
  Issue Type: Bug
  Components: Table SQL / Planner
Affects Versions: 1.19.0
Reporter: Matthias Pohl


{{IncrementalGroupAggregateRestoreTest.testRestore}} fails on {{master}}:
{code}
Jan 08 18:53:18 18:53:18.406 [ERROR] Tests run: 3, Failures: 1, Errors: 0, 
Skipped: 1, Time elapsed: 8.706 s <<< FAILURE! -- in 
org.apache.flink.table.planner.plan.nodes.exec.stream.IncrementalGroupAggregateRestoreTest
Jan 08 18:53:18 18:53:18.406 [ERROR] 
org.apache.flink.table.planner.plan.nodes.exec.stream.IncrementalGroupAggregateRestoreTest.testRestore(TableTestProgram,
 ExecNodeMetadata)[2] -- Time elapsed: 1.368 s <<< FAILURE!
Jan 08 18:53:18 java.lang.AssertionError: 
Jan 08 18:53:18 
Jan 08 18:53:18 Expecting actual:
Jan 08 18:53:18   ["+I[1, 5, 2, 3]",
Jan 08 18:53:18 "+I[2, 2, 1, 1]",
Jan 08 18:53:18 "-U[1, 5, 2, 3]",
Jan 08 18:53:18 "+U[1, 3, 2, 2]",
Jan 08 18:53:18 "-U[1, 3, 2, 2]",
Jan 08 18:53:18 "+U[1, 9, 3, 4]"]
Jan 08 18:53:18 to contain exactly in any order:
Jan 08 18:53:18   ["+I[1, 5, 2, 3]", "+I[2, 2, 1, 1]", "-U[1, 5, 2, 3]", "+U[1, 
9, 3, 4]"]
Jan 08 18:53:18 but the following elements were unexpected:
Jan 08 18:53:18   ["+U[1, 3, 2, 2]", "-U[1, 3, 2, 2]"]
Jan 08 18:53:18 
Jan 08 18:53:18 at 
org.apache.flink.table.planner.plan.nodes.exec.testutils.RestoreTestBase.testRestore(RestoreTestBase.java:292)
Jan 08 18:53:18 at java.lang.reflect.Method.invoke(Method.java:498)
[...]
{code}

https://dev.azure.com/apache-flink/apache-flink/_build/results?buildId=56110&view=logs&j=0c940707-2659-5648-cbe6-a1ad63045f0a&t=075c2716-8010-5565-fe08-3c4bb45824a4&l=10822



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] Accept Flink CDC into Apache Flink

[gongzhongqiang]

+1 non-binding

Best,
Zhongqiang

Leonard Xu  于2024年1月9日周二 15:05写道：

> Hello all,
>
> This is the official vote whether to accept the Flink CDC code contribution
>  to Apache Flink.
>
> The current Flink CDC code, documentation, and website can be
> found here:
> code: https://github.com/ververica/flink-cdc-connectors <
> https://github.com/ververica/flink-cdc-connectors>
> docs: https://ververica.github.io/flink-cdc-connectors/ <
> https://ververica.github.io/flink-cdc-connectors/>
>
> This vote should capture whether the Apache Flink community is interested
> in accepting, maintaining, and evolving Flink CDC.
>
> Regarding my original proposal[1] in the dev mailing list, I firmly believe
> that this initiative aligns perfectly with Flink. For the Flink community,
> it represents an opportunity to bolster Flink's competitive edge in
> streaming
> data integration, fostering the robust growth and prosperity of the Apache
> Flink
> ecosystem. For the Flink CDC project, becoming a sub-project of Apache
> Flink
> means becoming an integral part of a neutral open-source community,
> capable of
> attracting a more diverse pool of contributors.
>
> All Flink CDC maintainers are dedicated to continuously contributing to
> achieve
> seamless integration with Flink. Additionally, PMC members like Jark,
> Qingsheng,
> and I are willing to infacilitate the expansion of contributors and
> committers to
> effectively maintain this new sub-project.
>
> This is a "Adoption of a new Codebase" vote as per the Flink bylaws [2].
> Only PMC votes are binding. The vote will be open at least 7 days
> (excluding weekends), meaning until Thursday January 18 12:00 UTC, or
> until we
> achieve the 2/3rd majority. We will follow the instructions in the Flink
> Bylaws
> in the case of insufficient active binding voters:
>
> > 1. Wait until the minimum length of the voting passes.
> > 2. Publicly reach out via personal email to the remaining binding voters
> in the
> voting mail thread for at least 2 attempts with at least 7 days between
> two attempts.
> > 3. If the binding voter being contacted still failed to respond after
> all the attempts,
> the binding voter will be considered as inactive for the purpose of this
> particular voting.
>
> Welcome voting !
>
> Best,
> Leonard
> [1] https://lists.apache.org/thread/o7klnbsotmmql999bnwmdgo56b6kxx9l
> [2]
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026

Re: [VOTE] Accept Flink CDC into Apache Flink

[Sergey Nuyanzin]

+1 (non-binding)

On Tue, Jan 9, 2024 at 9:25 AM gongzhongqiang 
wrote:

> +1 non-binding
>
> Best,
> Zhongqiang
>
> Leonard Xu  于2024年1月9日周二 15:05写道：
>
> > Hello all,
> >
> > This is the official vote whether to accept the Flink CDC code
> contribution
> >  to Apache Flink.
> >
> > The current Flink CDC code, documentation, and website can be
> > found here:
> > code: https://github.com/ververica/flink-cdc-connectors <
> > https://github.com/ververica/flink-cdc-connectors>
> > docs: https://ververica.github.io/flink-cdc-connectors/ <
> > https://ververica.github.io/flink-cdc-connectors/>
> >
> > This vote should capture whether the Apache Flink community is interested
> > in accepting, maintaining, and evolving Flink CDC.
> >
> > Regarding my original proposal[1] in the dev mailing list, I firmly
> believe
> > that this initiative aligns perfectly with Flink. For the Flink
> community,
> > it represents an opportunity to bolster Flink's competitive edge in
> > streaming
> > data integration, fostering the robust growth and prosperity of the
> Apache
> > Flink
> > ecosystem. For the Flink CDC project, becoming a sub-project of Apache
> > Flink
> > means becoming an integral part of a neutral open-source community,
> > capable of
> > attracting a more diverse pool of contributors.
> >
> > All Flink CDC maintainers are dedicated to continuously contributing to
> > achieve
> > seamless integration with Flink. Additionally, PMC members like Jark,
> > Qingsheng,
> > and I are willing to infacilitate the expansion of contributors and
> > committers to
> > effectively maintain this new sub-project.
> >
> > This is a "Adoption of a new Codebase" vote as per the Flink bylaws [2].
> > Only PMC votes are binding. The vote will be open at least 7 days
> > (excluding weekends), meaning until Thursday January 18 12:00 UTC, or
> > until we
> > achieve the 2/3rd majority. We will follow the instructions in the Flink
> > Bylaws
> > in the case of insufficient active binding voters:
> >
> > > 1. Wait until the minimum length of the voting passes.
> > > 2. Publicly reach out via personal email to the remaining binding
> voters
> > in the
> > voting mail thread for at least 2 attempts with at least 7 days between
> > two attempts.
> > > 3. If the binding voter being contacted still failed to respond after
> > all the attempts,
> > the binding voter will be considered as inactive for the purpose of this
> > particular voting.
> >
> > Welcome voting !
> >
> > Best,
> > Leonard
> > [1] https://lists.apache.org/thread/o7klnbsotmmql999bnwmdgo56b6kxx9l
> > [2]
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
>


-- 
Best regards,
Sergey

Re: [VOTE] Accept Flink CDC into Apache Flink

[Lincoln Lee]

+1

Best,
Lincoln Lee


Sergey Nuyanzin  于2024年1月9日周二 16:33写道：

> +1 (non-binding)
>
> On Tue, Jan 9, 2024 at 9:25 AM gongzhongqiang 
> wrote:
>
> > +1 non-binding
> >
> > Best,
> > Zhongqiang
> >
> > Leonard Xu  于2024年1月9日周二 15:05写道：
> >
> > > Hello all,
> > >
> > > This is the official vote whether to accept the Flink CDC code
> > contribution
> > >  to Apache Flink.
> > >
> > > The current Flink CDC code, documentation, and website can be
> > > found here:
> > > code: https://github.com/ververica/flink-cdc-connectors <
> > > https://github.com/ververica/flink-cdc-connectors>
> > > docs: https://ververica.github.io/flink-cdc-connectors/ <
> > > https://ververica.github.io/flink-cdc-connectors/>
> > >
> > > This vote should capture whether the Apache Flink community is
> interested
> > > in accepting, maintaining, and evolving Flink CDC.
> > >
> > > Regarding my original proposal[1] in the dev mailing list, I firmly
> > believe
> > > that this initiative aligns perfectly with Flink. For the Flink
> > community,
> > > it represents an opportunity to bolster Flink's competitive edge in
> > > streaming
> > > data integration, fostering the robust growth and prosperity of the
> > Apache
> > > Flink
> > > ecosystem. For the Flink CDC project, becoming a sub-project of Apache
> > > Flink
> > > means becoming an integral part of a neutral open-source community,
> > > capable of
> > > attracting a more diverse pool of contributors.
> > >
> > > All Flink CDC maintainers are dedicated to continuously contributing to
> > > achieve
> > > seamless integration with Flink. Additionally, PMC members like Jark,
> > > Qingsheng,
> > > and I are willing to infacilitate the expansion of contributors and
> > > committers to
> > > effectively maintain this new sub-project.
> > >
> > > This is a "Adoption of a new Codebase" vote as per the Flink bylaws
> [2].
> > > Only PMC votes are binding. The vote will be open at least 7 days
> > > (excluding weekends), meaning until Thursday January 18 12:00 UTC, or
> > > until we
> > > achieve the 2/3rd majority. We will follow the instructions in the
> Flink
> > > Bylaws
> > > in the case of insufficient active binding voters:
> > >
> > > > 1. Wait until the minimum length of the voting passes.
> > > > 2. Publicly reach out via personal email to the remaining binding
> > voters
> > > in the
> > > voting mail thread for at least 2 attempts with at least 7 days between
> > > two attempts.
> > > > 3. If the binding voter being contacted still failed to respond after
> > > all the attempts,
> > > the binding voter will be considered as inactive for the purpose of
> this
> > > particular voting.
> > >
> > > Welcome voting !
> > >
> > > Best,
> > > Leonard
> > > [1] https://lists.apache.org/thread/o7klnbsotmmql999bnwmdgo56b6kxx9l
> > > [2]
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
> >
>
>
> --
> Best regards,
> Sergey
>

[jira] [Created] (FLINK-34039) The session group window agg operator does not split the session window when processing retrace records.

[xuyang (Jira)]

xuyang created FLINK-34039:
--

 Summary: The session group window agg operator does not split the 
session window when processing retrace records.
 Key: FLINK-34039
 URL: https://issues.apache.org/jira/browse/FLINK-34039
 Project: Flink
  Issue Type: Bug
  Components: Table SQL / Planner
Affects Versions: 1.18.0
Reporter: xuyang


Add the test in GroupWindowITCase to reproduce this bug.

 
{code:java}
@TestTemplate
def test(): Unit = {
  env.setParallelism(1)
  val upsertSourceDataId = registerData(
List(
  changelogRow("+I", "a", "no1", localDateTime(1L)),
  changelogRow("+I", "a", "no1", localDateTime(2L)),
  changelogRow("+I", "a", "no1", localDateTime(6L)),
  changelogRow("+I", "a", "no1", localDateTime(9L)),
  changelogRow("-D", "a", "no1", localDateTime(6L))
))
  tEnv.executeSql(s"""
 |CREATE TABLE upsert_currency (
 |  pk STRING,
 |  str STRING,
 |  currency_time TIMESTAMP(3),
 |  WATERMARK FOR currency_time AS currency_time - interval 
'5' SECOND
 |) WITH (
 |  'connector' = 'values',
 |  'changelog-mode' = 'I,UB,UA,D',
 |  'data-id' = '$upsertSourceDataId'
 |)
 |""".stripMargin)
  val sql =
"""
  |SELECT
  |pk,
  |COUNT(*) AS cnt,
  |SESSION_START(currency_time, INTERVAL '5' SECOND) as w_start,
  |SESSION_END(currency_time, INTERVAL '5' SECOND) as w_end
  |FROM upsert_currency
  |GROUP BY pk, SESSION(currency_time, INTERVAL '5' SECOND)
  |""".stripMargin
  val sink = new TestingAppendSink
  tEnv.sqlQuery(sql).toDataStream.addSink(sink)
  env.execute()
  println(sink.getAppendResults.sorted)
}{code}
The result is: 

 

 
{code:java}
a,3,1970-01-01T00:00:01,1970-01-01T00:00:14{code}
But if we change the source data as below:
{code:java}
val upsertSourceDataId = registerData(
  List(
changelogRow("+I", "a", "no1", localDateTime(1L)),
changelogRow("+I", "a", "no1", localDateTime(2L)),         
// changelogRow("+I", "a", "no1", localDateTime(6L)),
changelogRow("+I", "a", "no1", localDateTime(9L))
// changelogRow("-D", "a", "no1", localDateTime(6L))
  )) {code}
 

The result will be:
{code:java}
a,1,1970-01-01T00:00:09,1970-01-01T00:00:14
a,2,1970-01-01T00:00:01,1970-01-01T00:00:07{code}
When there is a minibatch operator upstream and CDC messages may be folded, the 
results of the session group window agg node may be different.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] Accept Flink CDC into Apache Flink

[Samrat Deb]

+1 (non binding)

Bests,
Samrat

Re: [VOTE] Accept Flink CDC into Apache Flink

[Hang Ruan]

+1 (non-binding)

Best,
Hang

gongzhongqiang  于2024年1月9日周二 16:25写道：

> +1 non-binding
>
> Best,
> Zhongqiang
>
> Leonard Xu  于2024年1月9日周二 15:05写道：
>
> > Hello all,
> >
> > This is the official vote whether to accept the Flink CDC code
> contribution
> >  to Apache Flink.
> >
> > The current Flink CDC code, documentation, and website can be
> > found here:
> > code: https://github.com/ververica/flink-cdc-connectors <
> > https://github.com/ververica/flink-cdc-connectors>
> > docs: https://ververica.github.io/flink-cdc-connectors/ <
> > https://ververica.github.io/flink-cdc-connectors/>
> >
> > This vote should capture whether the Apache Flink community is interested
> > in accepting, maintaining, and evolving Flink CDC.
> >
> > Regarding my original proposal[1] in the dev mailing list, I firmly
> believe
> > that this initiative aligns perfectly with Flink. For the Flink
> community,
> > it represents an opportunity to bolster Flink's competitive edge in
> > streaming
> > data integration, fostering the robust growth and prosperity of the
> Apache
> > Flink
> > ecosystem. For the Flink CDC project, becoming a sub-project of Apache
> > Flink
> > means becoming an integral part of a neutral open-source community,
> > capable of
> > attracting a more diverse pool of contributors.
> >
> > All Flink CDC maintainers are dedicated to continuously contributing to
> > achieve
> > seamless integration with Flink. Additionally, PMC members like Jark,
> > Qingsheng,
> > and I are willing to infacilitate the expansion of contributors and
> > committers to
> > effectively maintain this new sub-project.
> >
> > This is a "Adoption of a new Codebase" vote as per the Flink bylaws [2].
> > Only PMC votes are binding. The vote will be open at least 7 days
> > (excluding weekends), meaning until Thursday January 18 12:00 UTC, or
> > until we
> > achieve the 2/3rd majority. We will follow the instructions in the Flink
> > Bylaws
> > in the case of insufficient active binding voters:
> >
> > > 1. Wait until the minimum length of the voting passes.
> > > 2. Publicly reach out via personal email to the remaining binding
> voters
> > in the
> > voting mail thread for at least 2 attempts with at least 7 days between
> > two attempts.
> > > 3. If the binding voter being contacted still failed to respond after
> > all the attempts,
> > the binding voter will be considered as inactive for the purpose of this
> > particular voting.
> >
> > Welcome voting !
> >
> > Best,
> > Leonard
> > [1] https://lists.apache.org/thread/o7klnbsotmmql999bnwmdgo56b6kxx9l
> > [2]
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
>

Re: [DISCUSS][FLINK-31830] Align the Nullability Handling of ROW between SQL and TableAPI

[Dawid Wysakowicz]

Hey all,
First of all, sorry I have not read the entire thread. I just wanted to
make sure you take this one case into consideration.

As far as I know, we map java classes to SQL ROWs? E.g. it is possible to
have a POJO as a parameter to a UDF.
*class MyUDF {*
*  eval(MyPojo a)*
*}*




*class MyPojo { int f0; Integer f1;}*
I remember the problem with how nullability of a ROW's fields is handled
was mostly because in calcite its only goal is to support IS NULL function.

If we try to map a ROW to a POJO with the proposed strategy, that all
fields are nullable if the outer ROW is nullable we cannot represent the
above POJO.

The POJO's f0 field should be NOT NULL which is telling it is represented
as int . With the new proposed logic, all fields of a POJO would need to be
boxed, because all would be NULLABLE

Hope you can still incorporate this example into your design.
Best,
Dawid

On Thu, 4 Jan 2024 at 03:15, Jane Chan  wrote:

> Hi Timo,
>
> Thanks for your valuable feedback.
>
> How about we work together on this topic and create a FLIP for this? We
> > need more examples in a unified document. Currently, the proposal is
> split
> > across multiple Flink and Calcite JIRA issues and a ML discussion.
>
>
> That sounds like a great idea. A FLIP would provide a more precise and
> better-organized document, and let's fix it together.
>
> Towards several points you mentioned, here are my cents
>
> RelDataType is similarly just a type declaration. Please correct me if
> > I'm wrong but RelDataType itself also allows `ROW NOT
> > NULL`.
> >
>
> In the context of RelDataType, `ROW NOT NULL` is a
> legitimate type specification. However, I presume that the type you intend
> to refer to is `ROW`.
>
> Theoretically speaking, the answer is no and yes.
> **NO** It would not be able to create a type like `RecordType(INTEGER NOT
> NULL f0by using Calcite fluent API[1]. If the record nullability is true,
> then the inner field's nullability is set to true implicitly.
> **YES** It's conceptually viable to create a type like `RecordType(INTEGER
> NOT NULL f0)` by directly calling the constructor of RelRecordType.
> Nevertheless, the JavaDoc constructor summary[2] emphasizes that
> ctor#(StructKind, List, boolean) should only be called
> from a factory method.
>
> The following code snippet demonstrates the difference at the API level.
>
> @Test
> void testRelRecordType() {
>   // create an inner type INT NOT NULL
>   RelDataType innerFieldType =
>   new BasicSqlType(RelDataTypeSystem.DEFAULT, SqlTypeName.INTEGER);
>   RelDataTypeField f0 = new RelDataTypeFieldImpl("f0", 0, innerFieldType);
>
>   // Directly call RelRecordType ctor to specify the record level
> nullability
>
> // However, in practice, users are not recommended to do so
>   RelDataType r1 =
>   new RelRecordType(StructKind.FULLY_QUALIFIED,
> Collections.singletonList(f0), true);
>   // This will print r1: RecordType(INTEGER NOT NULL f0)
>   System.out.println("r1: " + r1.getFullTypeString());
>
>   // Use Calcite fluent API
>   RelDataTypeFactory calciteTypeFactory = new
> SqlTypeFactoryImpl(RelDataTypeSystem.DEFAULT);
>
>   RelDataType r2 =
>   new RelDataTypeFactory.Builder(calciteTypeFactory)
>   .add(f0)
>   .nullable(false) // field nullability will be overridden
> by record nullability
>   .nullableRecord(true)
>   .build();
>   // This will print r2: RecordType(INTEGER f0)
>   System.out.println("r2: " + r2.getFullTypeString());
>
>   // NOTE: replace type factory with flinkTypeFactory also get
> RecordType(INTEGER f0)
>   FlinkTypeFactory flinkTypeFactory =
>   ((PlannerBase) (((TableEnvironmentImpl)
> tableEnv).getPlanner())).getTypeFactory();
> }
>
>
> It's the factory or optimizer that performs necessary changes.
> > - It's up to the framework (i.e. planner or Table API) to decide what to
> > do with these declarations.
> >
>
> You're correct; theoretically, the responsibility for type declaration
> resides with the optimizer and framework. However, Flink allows users to
> create types like `ROW` through the public API, like
> `DataTypes.ROW(DataTypes.FIELD("f0", DataTypes.INT.notNull())).nullable()`.
> In contrast, Calcite restricts such actions(suppose they follow the best
> practice and use fluent API). Perhaps we can take a reference from
> Calcite's RelDataTypeFactory.Builder to align the behavior of table API to
> SQL.
>
>
> > MyPojo can be nullable, but i cannot. This is the reason why we decided
> > to introduce the current behavior. Complex structs are usually generated
> > from Table API or from the catalog (e.g. when mapping to schema registry
> > or some other external system). It could lead to other downstream
> > inconsistencies if we change the method above.
> >
>
> Correct me if I'm mistaken, but if `MyPojo myPojo = null`, we cannot
> conclude that `myPojo.i` is not null because an NPE will be thrown. And we
> can only safely say `myPo

Re: [VOTE] Accept Flink CDC into Apache Flink

[Rui Fan]

+1 (non-binding)

Best,
Rui

On Tue, Jan 9, 2024 at 4:41 PM Hang Ruan  wrote:

> +1 (non-binding)
>
> Best,
> Hang
>
> gongzhongqiang  于2024年1月9日周二 16:25写道：
>
> > +1 non-binding
> >
> > Best,
> > Zhongqiang
> >
> > Leonard Xu  于2024年1月9日周二 15:05写道：
> >
> > > Hello all,
> > >
> > > This is the official vote whether to accept the Flink CDC code
> > contribution
> > >  to Apache Flink.
> > >
> > > The current Flink CDC code, documentation, and website can be
> > > found here:
> > > code: https://github.com/ververica/flink-cdc-connectors <
> > > https://github.com/ververica/flink-cdc-connectors>
> > > docs: https://ververica.github.io/flink-cdc-connectors/ <
> > > https://ververica.github.io/flink-cdc-connectors/>
> > >
> > > This vote should capture whether the Apache Flink community is
> interested
> > > in accepting, maintaining, and evolving Flink CDC.
> > >
> > > Regarding my original proposal[1] in the dev mailing list, I firmly
> > believe
> > > that this initiative aligns perfectly with Flink. For the Flink
> > community,
> > > it represents an opportunity to bolster Flink's competitive edge in
> > > streaming
> > > data integration, fostering the robust growth and prosperity of the
> > Apache
> > > Flink
> > > ecosystem. For the Flink CDC project, becoming a sub-project of Apache
> > > Flink
> > > means becoming an integral part of a neutral open-source community,
> > > capable of
> > > attracting a more diverse pool of contributors.
> > >
> > > All Flink CDC maintainers are dedicated to continuously contributing to
> > > achieve
> > > seamless integration with Flink. Additionally, PMC members like Jark,
> > > Qingsheng,
> > > and I are willing to infacilitate the expansion of contributors and
> > > committers to
> > > effectively maintain this new sub-project.
> > >
> > > This is a "Adoption of a new Codebase" vote as per the Flink bylaws
> [2].
> > > Only PMC votes are binding. The vote will be open at least 7 days
> > > (excluding weekends), meaning until Thursday January 18 12:00 UTC, or
> > > until we
> > > achieve the 2/3rd majority. We will follow the instructions in the
> Flink
> > > Bylaws
> > > in the case of insufficient active binding voters:
> > >
> > > > 1. Wait until the minimum length of the voting passes.
> > > > 2. Publicly reach out via personal email to the remaining binding
> > voters
> > > in the
> > > voting mail thread for at least 2 attempts with at least 7 days between
> > > two attempts.
> > > > 3. If the binding voter being contacted still failed to respond after
> > > all the attempts,
> > > the binding voter will be considered as inactive for the purpose of
> this
> > > particular voting.
> > >
> > > Welcome voting !
> > >
> > > Best,
> > > Leonard
> > > [1] https://lists.apache.org/thread/o7klnbsotmmql999bnwmdgo56b6kxx9l
> > > [2]
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
> >
>

Re: Re: FLIP-413: Enable unaligned checkpoints by default

[Piotr Nowojski]

Hi!

I think this warning from the documentation is a bit over the top. Yes,
unaligned checkpoints in that regard are adding an extra source of
indeterminism, however please note that Flink doesn't give any guarantees
that the results will be the same after a recovery, as the order of the
records can change. AFAIR this warning has been added from the context of
the non-keyed exchanges, but some time later we were forced to disable
unaligned checkpoints on such exchanges. Which probably makes this warning
unnecessary.

Best,
Piotrek

wt., 9 sty 2024 o 02:05 Mason Chen  napisał(a):

> Hi Piotr,
>
> I also agree with Zhanghao's assessment on the limitations of unaligned
> checkpoints. Some of them are already handled properly by Flink, but in the
> case of the "Interplay with watermarks" limitation, it is quite confusing
> for a new user to find that their code doesn't generate consistent results
> with the default checkpoint configuration. Is there a way for Flink to
> detect and handle this situation correctly?
>
> [1]
>
> https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/ops/state/checkpointing_under_backpressure/#limitations
>
> Best,
> Mason
>
> On Mon, Jan 8, 2024 at 2:01 AM yangpmldl  wrote:
>
> > 退订
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > At 2024-01-08 17:45:01, "Piotr Nowojski"  wrote:
> > >Hi thanks for the responses,
> > >
> > >And thanks for pointing out the jobs upgrade issue. Indeed that has
> > >slipped my mind. I was mistakenly
> > >thinking that we are supporting all upgrades only via savepoint. Anyway,
> > >maybe in that case we should
> > >guide users towards that? Using savepoints for upgrades? That would be
> > even
> > >easier to understand
> > >for the users:
> > >- use unaligned checkpoints for checkpoints
> > >- use savepoints for any changes in the job/version upgrades
> > >
> > >There is a downside, that savepoints are always full, while aligned
> > >checkpoints can be incremental.
> > >
> > >WDYT?
> > >
> > >Regarding the value for the timeout, I would also be fine with 30s.
> Indeed
> > >that's a safer default.
> > >
> > >> On a separate point, in the sentence below it seems to me it would be
> > >> clearer to say that in the unlikely scenario you've described, the
> > change
> > >> would "significantly increase checkpoint sizes" -- assuming I
> understand
> > >> things correctly.
> > >
> > >I've reworded that paragraph.
> > >
> > >Best,
> > >Piotrek
> > >
> > >
> > >
> > >pon., 8 sty 2024 o 08:02 Rui Fan <1996fan...@gmail.com> napisał(a):
> > >
> > >> Thanks to Piotr driving this proposal!
> > >>
> > >> Enabling unaligned checkpoint with aligned checkpoints timeout
> > >> is fine for me. I'm not sure if aligned checkpoints timeout =5s is
> > >> too aggressive. If the unaligned checkpoint is enabled by default
> > >> for all jobs, I recommend that the aligned checkpoints timeout be
> > >> at least 30s.
> > >>
> > >> If the 30s is too big for some of the flink jobs, flink users can turn
> > >> it down by themselves.
> > >>
> > >> To David, Ken and Zhanghao:
> > >>
> > >> Unaligned checkpoint indeed has some limitations than aligned
> > checkpoint,
> > >> but if we set aligned checkpoints timeout= 30s or 60s, it means
> > >> when a job can be completed within 30s or 60s, this job still uses the
> > >> aligned checkpoint (it doesn't introduce any extra effort).
> > >> When the checkpoint cannot be completed within aligned checkpoints
> > timeout,
> > >> the aligned checkpoint will be switched to the unaligned checkpoint
> > >> The unaligned checkpoint can be completed when backpressure is severe.
> > >>
> > >> In brief, when backpressure is low, enabling them without any effort.
> > >> when backpressure is high, enabling them has some benefits.
> > >>
> > >> So I think it doesn't have too many risks when aligned checkpoints
> > timeout
> > >> is set to 30s or above. WDYT?
> > >>
> > >> Best,
> > >> Rui
> > >>
> > >> On Mon, Jan 8, 2024 at 12:57 PM Zhanghao Chen <
> > zhanghao.c...@outlook.com>
> > >> wrote:
> > >>
> > >> > Hi Piotr,
> > >> >
> > >> > As a platform administer who runs kilos of Flink jobs, I'd be
> against
> > the
> > >> > idea to enable unaligned cp by default for our jobs. It may help a
> > >> > significant portion of the users, but the subtle issues around
> > unaligned
> > >> CP
> > >> > for a few jobs will probably raise a lot more on-calls and
> incidents.
> > >> From
> > >> > my point of view, we'd better not enable it by default before
> removing
> > >> all
> > >> > the limitations listed in
> > >> >
> > >>
> >
> https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/ops/state/checkpointing_under_backpressure/#limitations
> > >> > .
> > >> >
> > >> > Best,
> > >> > Zhanghao Chen
> > >> > 
> > >> > From: Piotr Nowojski 
> > >> > Sent: Friday, January 5, 2024 21:41
> > >> > To: dev 
> > >> > Subject: FLIP-413: Enable unaligned checkpoints by default
> > >> >
> > >> > Hi!
> > >> >
> > >> > I would like

Re: [VOTE] Accept Flink CDC into Apache Flink

[Yu Li]

+1 (binding)

Good luck!

Best Regards,
Yu


On Tue, 9 Jan 2024 at 16:49, Rui Fan <1996fan...@gmail.com> wrote:

> +1 (non-binding)
>
> Best,
> Rui
>
> On Tue, Jan 9, 2024 at 4:41 PM Hang Ruan  wrote:
>
> > +1 (non-binding)
> >
> > Best,
> > Hang
> >
> > gongzhongqiang  于2024年1月9日周二 16:25写道：
> >
> > > +1 non-binding
> > >
> > > Best,
> > > Zhongqiang
> > >
> > > Leonard Xu  于2024年1月9日周二 15:05写道：
> > >
> > > > Hello all,
> > > >
> > > > This is the official vote whether to accept the Flink CDC code
> > > contribution
> > > >  to Apache Flink.
> > > >
> > > > The current Flink CDC code, documentation, and website can be
> > > > found here:
> > > > code: https://github.com/ververica/flink-cdc-connectors <
> > > > https://github.com/ververica/flink-cdc-connectors>
> > > > docs: https://ververica.github.io/flink-cdc-connectors/ <
> > > > https://ververica.github.io/flink-cdc-connectors/>
> > > >
> > > > This vote should capture whether the Apache Flink community is
> > interested
> > > > in accepting, maintaining, and evolving Flink CDC.
> > > >
> > > > Regarding my original proposal[1] in the dev mailing list, I firmly
> > > believe
> > > > that this initiative aligns perfectly with Flink. For the Flink
> > > community,
> > > > it represents an opportunity to bolster Flink's competitive edge in
> > > > streaming
> > > > data integration, fostering the robust growth and prosperity of the
> > > Apache
> > > > Flink
> > > > ecosystem. For the Flink CDC project, becoming a sub-project of
> Apache
> > > > Flink
> > > > means becoming an integral part of a neutral open-source community,
> > > > capable of
> > > > attracting a more diverse pool of contributors.
> > > >
> > > > All Flink CDC maintainers are dedicated to continuously contributing
> to
> > > > achieve
> > > > seamless integration with Flink. Additionally, PMC members like Jark,
> > > > Qingsheng,
> > > > and I are willing to infacilitate the expansion of contributors and
> > > > committers to
> > > > effectively maintain this new sub-project.
> > > >
> > > > This is a "Adoption of a new Codebase" vote as per the Flink bylaws
> > [2].
> > > > Only PMC votes are binding. The vote will be open at least 7 days
> > > > (excluding weekends), meaning until Thursday January 18 12:00 UTC, or
> > > > until we
> > > > achieve the 2/3rd majority. We will follow the instructions in the
> > Flink
> > > > Bylaws
> > > > in the case of insufficient active binding voters:
> > > >
> > > > > 1. Wait until the minimum length of the voting passes.
> > > > > 2. Publicly reach out via personal email to the remaining binding
> > > voters
> > > > in the
> > > > voting mail thread for at least 2 attempts with at least 7 days
> between
> > > > two attempts.
> > > > > 3. If the binding voter being contacted still failed to respond
> after
> > > > all the attempts,
> > > > the binding voter will be considered as inactive for the purpose of
> > this
> > > > particular voting.
> > > >
> > > > Welcome voting !
> > > >
> > > > Best,
> > > > Leonard
> > > > [1] https://lists.apache.org/thread/o7klnbsotmmql999bnwmdgo56b6kxx9l
> > > > [2]
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
> > >
> >
>

Re: [VOTE] Accept Flink CDC into Apache Flink

[Guowei Ma]

+1 (binding)
Best,
Guowei


On Tue, Jan 9, 2024 at 4:49 PM Rui Fan <1996fan...@gmail.com> wrote:

> +1 (non-binding)
>
> Best,
> Rui
>
> On Tue, Jan 9, 2024 at 4:41 PM Hang Ruan  wrote:
>
> > +1 (non-binding)
> >
> > Best,
> > Hang
> >
> > gongzhongqiang  于2024年1月9日周二 16:25写道：
> >
> > > +1 non-binding
> > >
> > > Best,
> > > Zhongqiang
> > >
> > > Leonard Xu  于2024年1月9日周二 15:05写道：
> > >
> > > > Hello all,
> > > >
> > > > This is the official vote whether to accept the Flink CDC code
> > > contribution
> > > >  to Apache Flink.
> > > >
> > > > The current Flink CDC code, documentation, and website can be
> > > > found here:
> > > > code: https://github.com/ververica/flink-cdc-connectors <
> > > > https://github.com/ververica/flink-cdc-connectors>
> > > > docs: https://ververica.github.io/flink-cdc-connectors/ <
> > > > https://ververica.github.io/flink-cdc-connectors/>
> > > >
> > > > This vote should capture whether the Apache Flink community is
> > interested
> > > > in accepting, maintaining, and evolving Flink CDC.
> > > >
> > > > Regarding my original proposal[1] in the dev mailing list, I firmly
> > > believe
> > > > that this initiative aligns perfectly with Flink. For the Flink
> > > community,
> > > > it represents an opportunity to bolster Flink's competitive edge in
> > > > streaming
> > > > data integration, fostering the robust growth and prosperity of the
> > > Apache
> > > > Flink
> > > > ecosystem. For the Flink CDC project, becoming a sub-project of
> Apache
> > > > Flink
> > > > means becoming an integral part of a neutral open-source community,
> > > > capable of
> > > > attracting a more diverse pool of contributors.
> > > >
> > > > All Flink CDC maintainers are dedicated to continuously contributing
> to
> > > > achieve
> > > > seamless integration with Flink. Additionally, PMC members like Jark,
> > > > Qingsheng,
> > > > and I are willing to infacilitate the expansion of contributors and
> > > > committers to
> > > > effectively maintain this new sub-project.
> > > >
> > > > This is a "Adoption of a new Codebase" vote as per the Flink bylaws
> > [2].
> > > > Only PMC votes are binding. The vote will be open at least 7 days
> > > > (excluding weekends), meaning until Thursday January 18 12:00 UTC, or
> > > > until we
> > > > achieve the 2/3rd majority. We will follow the instructions in the
> > Flink
> > > > Bylaws
> > > > in the case of insufficient active binding voters:
> > > >
> > > > > 1. Wait until the minimum length of the voting passes.
> > > > > 2. Publicly reach out via personal email to the remaining binding
> > > voters
> > > > in the
> > > > voting mail thread for at least 2 attempts with at least 7 days
> between
> > > > two attempts.
> > > > > 3. If the binding voter being contacted still failed to respond
> after
> > > > all the attempts,
> > > > the binding voter will be considered as inactive for the purpose of
> > this
> > > > particular voting.
> > > >
> > > > Welcome voting !
> > > >
> > > > Best,
> > > > Leonard
> > > > [1] https://lists.apache.org/thread/o7klnbsotmmql999bnwmdgo56b6kxx9l
> > > > [2]
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
> > >
> >
>

[jira] [Created] (FLINK-34040) ScalaSerializersMigrationTest.testStableAnonymousClassnameGeneration fails in GHA with JDK 17 and 21

[Matthias Pohl (Jira)]

Matthias Pohl created FLINK-34040:
-

 Summary: 
ScalaSerializersMigrationTest.testStableAnonymousClassnameGeneration fails in 
GHA with JDK 17 and 21
 Key: FLINK-34040
 URL: https://issues.apache.org/jira/browse/FLINK-34040
 Project: Flink
  Issue Type: Sub-task
  Components: API / Scala, Build System / CI
Affects Versions: 1.19.0
Reporter: Matthias Pohl


{code}
Error: 13:05:23 13:05:23.538 [ERROR] Tests run: 1, Failures: 1, Errors: 0, 
Skipped: 0, Time elapsed: 0.375 s <<< FAILURE! -- in 
org.apache.flink.api.scala.migration.ScalaSerializersMigrationTest
Error: 13:05:23 13:05:23.538 [ERROR] 
org.apache.flink.api.scala.migration.ScalaSerializersMigrationTest.testStableAnonymousClassnameGeneration
 -- Time elapsed: 0.371 s <<< FAILURE!
Jan 07 13:05:23 org.junit.ComparisonFailure: 
expected:<...MigrationTest$$anon$[8]> but was:<...MigrationTest$$anon$[1]>
Jan 07 13:05:23 at org.junit.Assert.assertEquals(Assert.java:117)
Jan 07 13:05:23 at org.junit.Assert.assertEquals(Assert.java:146)
Jan 07 13:05:23 at 
org.apache.flink.api.scala.migration.ScalaSerializersMigrationTest.testStableAnonymousClassnameGeneration(ScalaSerializersMigrationTest.scala:60)
Jan 07 13:05:23 at 
java.base/java.lang.reflect.Method.invoke(Method.java:580)
{code}

The error only happens in the [master GHA 
nightly|https://github.com/XComp/flink/actions/workflows/nightly-dev.yml] for 
JDK 17 and 21.

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] Accept Flink CDC into Apache Flink

[Robert Metzger]

+1 (binding)


On Tue, Jan 9, 2024 at 9:54 AM Guowei Ma  wrote:

> +1 (binding)
> Best,
> Guowei
>
>
> On Tue, Jan 9, 2024 at 4:49 PM Rui Fan <1996fan...@gmail.com> wrote:
>
> > +1 (non-binding)
> >
> > Best,
> > Rui
> >
> > On Tue, Jan 9, 2024 at 4:41 PM Hang Ruan  wrote:
> >
> > > +1 (non-binding)
> > >
> > > Best,
> > > Hang
> > >
> > > gongzhongqiang  于2024年1月9日周二 16:25写道：
> > >
> > > > +1 non-binding
> > > >
> > > > Best,
> > > > Zhongqiang
> > > >
> > > > Leonard Xu  于2024年1月9日周二 15:05写道：
> > > >
> > > > > Hello all,
> > > > >
> > > > > This is the official vote whether to accept the Flink CDC code
> > > > contribution
> > > > >  to Apache Flink.
> > > > >
> > > > > The current Flink CDC code, documentation, and website can be
> > > > > found here:
> > > > > code: https://github.com/ververica/flink-cdc-connectors <
> > > > > https://github.com/ververica/flink-cdc-connectors>
> > > > > docs: https://ververica.github.io/flink-cdc-connectors/ <
> > > > > https://ververica.github.io/flink-cdc-connectors/>
> > > > >
> > > > > This vote should capture whether the Apache Flink community is
> > > interested
> > > > > in accepting, maintaining, and evolving Flink CDC.
> > > > >
> > > > > Regarding my original proposal[1] in the dev mailing list, I firmly
> > > > believe
> > > > > that this initiative aligns perfectly with Flink. For the Flink
> > > > community,
> > > > > it represents an opportunity to bolster Flink's competitive edge in
> > > > > streaming
> > > > > data integration, fostering the robust growth and prosperity of the
> > > > Apache
> > > > > Flink
> > > > > ecosystem. For the Flink CDC project, becoming a sub-project of
> > Apache
> > > > > Flink
> > > > > means becoming an integral part of a neutral open-source community,
> > > > > capable of
> > > > > attracting a more diverse pool of contributors.
> > > > >
> > > > > All Flink CDC maintainers are dedicated to continuously
> contributing
> > to
> > > > > achieve
> > > > > seamless integration with Flink. Additionally, PMC members like
> Jark,
> > > > > Qingsheng,
> > > > > and I are willing to infacilitate the expansion of contributors and
> > > > > committers to
> > > > > effectively maintain this new sub-project.
> > > > >
> > > > > This is a "Adoption of a new Codebase" vote as per the Flink bylaws
> > > [2].
> > > > > Only PMC votes are binding. The vote will be open at least 7 days
> > > > > (excluding weekends), meaning until Thursday January 18 12:00 UTC,
> or
> > > > > until we
> > > > > achieve the 2/3rd majority. We will follow the instructions in the
> > > Flink
> > > > > Bylaws
> > > > > in the case of insufficient active binding voters:
> > > > >
> > > > > > 1. Wait until the minimum length of the voting passes.
> > > > > > 2. Publicly reach out via personal email to the remaining binding
> > > > voters
> > > > > in the
> > > > > voting mail thread for at least 2 attempts with at least 7 days
> > between
> > > > > two attempts.
> > > > > > 3. If the binding voter being contacted still failed to respond
> > after
> > > > > all the attempts,
> > > > > the binding voter will be considered as inactive for the purpose of
> > > this
> > > > > particular voting.
> > > > >
> > > > > Welcome voting !
> > > > >
> > > > > Best,
> > > > > Leonard
> > > > > [1]
> https://lists.apache.org/thread/o7klnbsotmmql999bnwmdgo56b6kxx9l
> > > > > [2]
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
> > > >
> > >
> >
>

Re: [VOTE] Accept Flink CDC into Apache Flink

[Yangze Guo]

+1 (non-binding)

Best,
Yangze Guo

On Tue, Jan 9, 2024 at 5:06 PM Robert Metzger  wrote:
>
> +1 (binding)
>
>
> On Tue, Jan 9, 2024 at 9:54 AM Guowei Ma  wrote:
>
> > +1 (binding)
> > Best,
> > Guowei
> >
> >
> > On Tue, Jan 9, 2024 at 4:49 PM Rui Fan <1996fan...@gmail.com> wrote:
> >
> > > +1 (non-binding)
> > >
> > > Best,
> > > Rui
> > >
> > > On Tue, Jan 9, 2024 at 4:41 PM Hang Ruan  wrote:
> > >
> > > > +1 (non-binding)
> > > >
> > > > Best,
> > > > Hang
> > > >
> > > > gongzhongqiang  于2024年1月9日周二 16:25写道：
> > > >
> > > > > +1 non-binding
> > > > >
> > > > > Best,
> > > > > Zhongqiang
> > > > >
> > > > > Leonard Xu  于2024年1月9日周二 15:05写道：
> > > > >
> > > > > > Hello all,
> > > > > >
> > > > > > This is the official vote whether to accept the Flink CDC code
> > > > > contribution
> > > > > >  to Apache Flink.
> > > > > >
> > > > > > The current Flink CDC code, documentation, and website can be
> > > > > > found here:
> > > > > > code: https://github.com/ververica/flink-cdc-connectors <
> > > > > > https://github.com/ververica/flink-cdc-connectors>
> > > > > > docs: https://ververica.github.io/flink-cdc-connectors/ <
> > > > > > https://ververica.github.io/flink-cdc-connectors/>
> > > > > >
> > > > > > This vote should capture whether the Apache Flink community is
> > > > interested
> > > > > > in accepting, maintaining, and evolving Flink CDC.
> > > > > >
> > > > > > Regarding my original proposal[1] in the dev mailing list, I firmly
> > > > > believe
> > > > > > that this initiative aligns perfectly with Flink. For the Flink
> > > > > community,
> > > > > > it represents an opportunity to bolster Flink's competitive edge in
> > > > > > streaming
> > > > > > data integration, fostering the robust growth and prosperity of the
> > > > > Apache
> > > > > > Flink
> > > > > > ecosystem. For the Flink CDC project, becoming a sub-project of
> > > Apache
> > > > > > Flink
> > > > > > means becoming an integral part of a neutral open-source community,
> > > > > > capable of
> > > > > > attracting a more diverse pool of contributors.
> > > > > >
> > > > > > All Flink CDC maintainers are dedicated to continuously
> > contributing
> > > to
> > > > > > achieve
> > > > > > seamless integration with Flink. Additionally, PMC members like
> > Jark,
> > > > > > Qingsheng,
> > > > > > and I are willing to infacilitate the expansion of contributors and
> > > > > > committers to
> > > > > > effectively maintain this new sub-project.
> > > > > >
> > > > > > This is a "Adoption of a new Codebase" vote as per the Flink bylaws
> > > > [2].
> > > > > > Only PMC votes are binding. The vote will be open at least 7 days
> > > > > > (excluding weekends), meaning until Thursday January 18 12:00 UTC,
> > or
> > > > > > until we
> > > > > > achieve the 2/3rd majority. We will follow the instructions in the
> > > > Flink
> > > > > > Bylaws
> > > > > > in the case of insufficient active binding voters:
> > > > > >
> > > > > > > 1. Wait until the minimum length of the voting passes.
> > > > > > > 2. Publicly reach out via personal email to the remaining binding
> > > > > voters
> > > > > > in the
> > > > > > voting mail thread for at least 2 attempts with at least 7 days
> > > between
> > > > > > two attempts.
> > > > > > > 3. If the binding voter being contacted still failed to respond
> > > after
> > > > > > all the attempts,
> > > > > > the binding voter will be considered as inactive for the purpose of
> > > > this
> > > > > > particular voting.
> > > > > >
> > > > > > Welcome voting !
> > > > > >
> > > > > > Best,
> > > > > > Leonard
> > > > > > [1]
> > https://lists.apache.org/thread/o7klnbsotmmql999bnwmdgo56b6kxx9l
> > > > > > [2]
> > > > > >
> > > > >
> > > >
> > >
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
> > > > >
> > > >
> > >
> >

Re: [VOTE] Accept Flink CDC into Apache Flink

[Leonard Xu]

+1(binding)

Best,
Leonard

> 2024年1月9日 下午5:08，Yangze Guo  写道：
> 
> +1 (non-binding)
> 
> Best,
> Yangze Guo
> 
> On Tue, Jan 9, 2024 at 5:06 PM Robert Metzger  wrote:
>> 
>> +1 (binding)
>> 
>> 
>> On Tue, Jan 9, 2024 at 9:54 AM Guowei Ma  wrote:
>> 
>>> +1 (binding)
>>> Best,
>>> Guowei
>>> 
>>> 
>>> On Tue, Jan 9, 2024 at 4:49 PM Rui Fan <1996fan...@gmail.com> wrote:
>>> 
 +1 (non-binding)
 
 Best,
 Rui
 
 On Tue, Jan 9, 2024 at 4:41 PM Hang Ruan  wrote:
 
> +1 (non-binding)
> 
> Best,
> Hang
> 
> gongzhongqiang  于2024年1月9日周二 16:25写道：
> 
>> +1 non-binding
>> 
>> Best,
>> Zhongqiang
>> 
>> Leonard Xu  于2024年1月9日周二 15:05写道：
>> 
>>> Hello all,
>>> 
>>> This is the official vote whether to accept the Flink CDC code
>> contribution
>>> to Apache Flink.
>>> 
>>> The current Flink CDC code, documentation, and website can be
>>> found here:
>>> code: https://github.com/ververica/flink-cdc-connectors <
>>> https://github.com/ververica/flink-cdc-connectors>
>>> docs: https://ververica.github.io/flink-cdc-connectors/ <
>>> https://ververica.github.io/flink-cdc-connectors/>
>>> 
>>> This vote should capture whether the Apache Flink community is
> interested
>>> in accepting, maintaining, and evolving Flink CDC.
>>> 
>>> Regarding my original proposal[1] in the dev mailing list, I firmly
>> believe
>>> that this initiative aligns perfectly with Flink. For the Flink
>> community,
>>> it represents an opportunity to bolster Flink's competitive edge in
>>> streaming
>>> data integration, fostering the robust growth and prosperity of the
>> Apache
>>> Flink
>>> ecosystem. For the Flink CDC project, becoming a sub-project of
 Apache
>>> Flink
>>> means becoming an integral part of a neutral open-source community,
>>> capable of
>>> attracting a more diverse pool of contributors.
>>> 
>>> All Flink CDC maintainers are dedicated to continuously
>>> contributing
 to
>>> achieve
>>> seamless integration with Flink. Additionally, PMC members like
>>> Jark,
>>> Qingsheng,
>>> and I are willing to infacilitate the expansion of contributors and
>>> committers to
>>> effectively maintain this new sub-project.
>>> 
>>> This is a "Adoption of a new Codebase" vote as per the Flink bylaws
> [2].
>>> Only PMC votes are binding. The vote will be open at least 7 days
>>> (excluding weekends), meaning until Thursday January 18 12:00 UTC,
>>> or
>>> until we
>>> achieve the 2/3rd majority. We will follow the instructions in the
> Flink
>>> Bylaws
>>> in the case of insufficient active binding voters:
>>> 
 1. Wait until the minimum length of the voting passes.
 2. Publicly reach out via personal email to the remaining binding
>> voters
>>> in the
>>> voting mail thread for at least 2 attempts with at least 7 days
 between
>>> two attempts.
 3. If the binding voter being contacted still failed to respond
 after
>>> all the attempts,
>>> the binding voter will be considered as inactive for the purpose of
> this
>>> particular voting.
>>> 
>>> Welcome voting !
>>> 
>>> Best,
>>> Leonard
>>> [1]
>>> https://lists.apache.org/thread/o7klnbsotmmql999bnwmdgo56b6kxx9l
>>> [2]
>>> 
>> 
> 
 
>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
>> 
> 
 
>>> 

Re: [VOTE] Accept Flink CDC into Apache Flink

[Márton Balassi]

+1 (binding)

On Tue, Jan 9, 2024 at 10:15 AM Leonard Xu  wrote:

> +1(binding)
>
> Best,
> Leonard
>
> > 2024年1月9日 下午5:08，Yangze Guo  写道：
> >
> > +1 (non-binding)
> >
> > Best,
> > Yangze Guo
> >
> > On Tue, Jan 9, 2024 at 5:06 PM Robert Metzger 
> wrote:
> >>
> >> +1 (binding)
> >>
> >>
> >> On Tue, Jan 9, 2024 at 9:54 AM Guowei Ma  wrote:
> >>
> >>> +1 (binding)
> >>> Best,
> >>> Guowei
> >>>
> >>>
> >>> On Tue, Jan 9, 2024 at 4:49 PM Rui Fan <1996fan...@gmail.com> wrote:
> >>>
>  +1 (non-binding)
> 
>  Best,
>  Rui
> 
>  On Tue, Jan 9, 2024 at 4:41 PM Hang Ruan 
> wrote:
> 
> > +1 (non-binding)
> >
> > Best,
> > Hang
> >
> > gongzhongqiang  于2024年1月9日周二 16:25写道：
> >
> >> +1 non-binding
> >>
> >> Best,
> >> Zhongqiang
> >>
> >> Leonard Xu  于2024年1月9日周二 15:05写道：
> >>
> >>> Hello all,
> >>>
> >>> This is the official vote whether to accept the Flink CDC code
> >> contribution
> >>> to Apache Flink.
> >>>
> >>> The current Flink CDC code, documentation, and website can be
> >>> found here:
> >>> code: https://github.com/ververica/flink-cdc-connectors <
> >>> https://github.com/ververica/flink-cdc-connectors>
> >>> docs: https://ververica.github.io/flink-cdc-connectors/ <
> >>> https://ververica.github.io/flink-cdc-connectors/>
> >>>
> >>> This vote should capture whether the Apache Flink community is
> > interested
> >>> in accepting, maintaining, and evolving Flink CDC.
> >>>
> >>> Regarding my original proposal[1] in the dev mailing list, I firmly
> >> believe
> >>> that this initiative aligns perfectly with Flink. For the Flink
> >> community,
> >>> it represents an opportunity to bolster Flink's competitive edge in
> >>> streaming
> >>> data integration, fostering the robust growth and prosperity of the
> >> Apache
> >>> Flink
> >>> ecosystem. For the Flink CDC project, becoming a sub-project of
>  Apache
> >>> Flink
> >>> means becoming an integral part of a neutral open-source community,
> >>> capable of
> >>> attracting a more diverse pool of contributors.
> >>>
> >>> All Flink CDC maintainers are dedicated to continuously
> >>> contributing
>  to
> >>> achieve
> >>> seamless integration with Flink. Additionally, PMC members like
> >>> Jark,
> >>> Qingsheng,
> >>> and I are willing to infacilitate the expansion of contributors and
> >>> committers to
> >>> effectively maintain this new sub-project.
> >>>
> >>> This is a "Adoption of a new Codebase" vote as per the Flink bylaws
> > [2].
> >>> Only PMC votes are binding. The vote will be open at least 7 days
> >>> (excluding weekends), meaning until Thursday January 18 12:00 UTC,
> >>> or
> >>> until we
> >>> achieve the 2/3rd majority. We will follow the instructions in the
> > Flink
> >>> Bylaws
> >>> in the case of insufficient active binding voters:
> >>>
>  1. Wait until the minimum length of the voting passes.
>  2. Publicly reach out via personal email to the remaining binding
> >> voters
> >>> in the
> >>> voting mail thread for at least 2 attempts with at least 7 days
>  between
> >>> two attempts.
>  3. If the binding voter being contacted still failed to respond
>  after
> >>> all the attempts,
> >>> the binding voter will be considered as inactive for the purpose of
> > this
> >>> particular voting.
> >>>
> >>> Welcome voting !
> >>>
> >>> Best,
> >>> Leonard
> >>> [1]
> >>> https://lists.apache.org/thread/o7klnbsotmmql999bnwmdgo56b6kxx9l
> >>> [2]
> >>>
> >>
> >
> 
> >>>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
> >>
> >
> 
> >>>
>
>

Re: [VOTE] Accept Flink CDC into Apache Flink

[Yuxin Tan]

+1 (non-binding)

Best,
Yuxin


Márton Balassi  于2024年1月9日周二 17:25写道：

> +1 (binding)
>
> On Tue, Jan 9, 2024 at 10:15 AM Leonard Xu  wrote:
>
> > +1(binding)
> >
> > Best,
> > Leonard
> >
> > > 2024年1月9日 下午5:08，Yangze Guo  写道：
> > >
> > > +1 (non-binding)
> > >
> > > Best,
> > > Yangze Guo
> > >
> > > On Tue, Jan 9, 2024 at 5:06 PM Robert Metzger 
> > wrote:
> > >>
> > >> +1 (binding)
> > >>
> > >>
> > >> On Tue, Jan 9, 2024 at 9:54 AM Guowei Ma 
> wrote:
> > >>
> > >>> +1 (binding)
> > >>> Best,
> > >>> Guowei
> > >>>
> > >>>
> > >>> On Tue, Jan 9, 2024 at 4:49 PM Rui Fan <1996fan...@gmail.com> wrote:
> > >>>
> >  +1 (non-binding)
> > 
> >  Best,
> >  Rui
> > 
> >  On Tue, Jan 9, 2024 at 4:41 PM Hang Ruan 
> > wrote:
> > 
> > > +1 (non-binding)
> > >
> > > Best,
> > > Hang
> > >
> > > gongzhongqiang  于2024年1月9日周二 16:25写道：
> > >
> > >> +1 non-binding
> > >>
> > >> Best,
> > >> Zhongqiang
> > >>
> > >> Leonard Xu  于2024年1月9日周二 15:05写道：
> > >>
> > >>> Hello all,
> > >>>
> > >>> This is the official vote whether to accept the Flink CDC code
> > >> contribution
> > >>> to Apache Flink.
> > >>>
> > >>> The current Flink CDC code, documentation, and website can be
> > >>> found here:
> > >>> code: https://github.com/ververica/flink-cdc-connectors <
> > >>> https://github.com/ververica/flink-cdc-connectors>
> > >>> docs: https://ververica.github.io/flink-cdc-connectors/ <
> > >>> https://ververica.github.io/flink-cdc-connectors/>
> > >>>
> > >>> This vote should capture whether the Apache Flink community is
> > > interested
> > >>> in accepting, maintaining, and evolving Flink CDC.
> > >>>
> > >>> Regarding my original proposal[1] in the dev mailing list, I
> firmly
> > >> believe
> > >>> that this initiative aligns perfectly with Flink. For the Flink
> > >> community,
> > >>> it represents an opportunity to bolster Flink's competitive edge
> in
> > >>> streaming
> > >>> data integration, fostering the robust growth and prosperity of
> the
> > >> Apache
> > >>> Flink
> > >>> ecosystem. For the Flink CDC project, becoming a sub-project of
> >  Apache
> > >>> Flink
> > >>> means becoming an integral part of a neutral open-source
> community,
> > >>> capable of
> > >>> attracting a more diverse pool of contributors.
> > >>>
> > >>> All Flink CDC maintainers are dedicated to continuously
> > >>> contributing
> >  to
> > >>> achieve
> > >>> seamless integration with Flink. Additionally, PMC members like
> > >>> Jark,
> > >>> Qingsheng,
> > >>> and I are willing to infacilitate the expansion of contributors
> and
> > >>> committers to
> > >>> effectively maintain this new sub-project.
> > >>>
> > >>> This is a "Adoption of a new Codebase" vote as per the Flink
> bylaws
> > > [2].
> > >>> Only PMC votes are binding. The vote will be open at least 7 days
> > >>> (excluding weekends), meaning until Thursday January 18 12:00
> UTC,
> > >>> or
> > >>> until we
> > >>> achieve the 2/3rd majority. We will follow the instructions in
> the
> > > Flink
> > >>> Bylaws
> > >>> in the case of insufficient active binding voters:
> > >>>
> >  1. Wait until the minimum length of the voting passes.
> >  2. Publicly reach out via personal email to the remaining
> binding
> > >> voters
> > >>> in the
> > >>> voting mail thread for at least 2 attempts with at least 7 days
> >  between
> > >>> two attempts.
> >  3. If the binding voter being contacted still failed to respond
> >  after
> > >>> all the attempts,
> > >>> the binding voter will be considered as inactive for the purpose
> of
> > > this
> > >>> particular voting.
> > >>>
> > >>> Welcome voting !
> > >>>
> > >>> Best,
> > >>> Leonard
> > >>> [1]
> > >>> https://lists.apache.org/thread/o7klnbsotmmql999bnwmdgo56b6kxx9l
> > >>> [2]
> > >>>
> > >>
> > >
> > 
> > >>>
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
> > >>
> > >
> > 
> > >>>
> >
> >
>

Re: [VOTE] Accept Flink CDC into Apache Flink

[Feng Jin]

+1 (non-binding)

Best,
Feng Jin

On Tue, Jan 9, 2024 at 5:29 PM Yuxin Tan  wrote:

> +1 (non-binding)
>
> Best,
> Yuxin
>
>
> Márton Balassi  于2024年1月9日周二 17:25写道：
>
> > +1 (binding)
> >
> > On Tue, Jan 9, 2024 at 10:15 AM Leonard Xu  wrote:
> >
> > > +1(binding)
> > >
> > > Best,
> > > Leonard
> > >
> > > > 2024年1月9日 下午5:08，Yangze Guo  写道：
> > > >
> > > > +1 (non-binding)
> > > >
> > > > Best,
> > > > Yangze Guo
> > > >
> > > > On Tue, Jan 9, 2024 at 5:06 PM Robert Metzger 
> > > wrote:
> > > >>
> > > >> +1 (binding)
> > > >>
> > > >>
> > > >> On Tue, Jan 9, 2024 at 9:54 AM Guowei Ma 
> > wrote:
> > > >>
> > > >>> +1 (binding)
> > > >>> Best,
> > > >>> Guowei
> > > >>>
> > > >>>
> > > >>> On Tue, Jan 9, 2024 at 4:49 PM Rui Fan <1996fan...@gmail.com>
> wrote:
> > > >>>
> > >  +1 (non-binding)
> > > 
> > >  Best,
> > >  Rui
> > > 
> > >  On Tue, Jan 9, 2024 at 4:41 PM Hang Ruan 
> > > wrote:
> > > 
> > > > +1 (non-binding)
> > > >
> > > > Best,
> > > > Hang
> > > >
> > > > gongzhongqiang  于2024年1月9日周二 16:25写道：
> > > >
> > > >> +1 non-binding
> > > >>
> > > >> Best,
> > > >> Zhongqiang
> > > >>
> > > >> Leonard Xu  于2024年1月9日周二 15:05写道：
> > > >>
> > > >>> Hello all,
> > > >>>
> > > >>> This is the official vote whether to accept the Flink CDC code
> > > >> contribution
> > > >>> to Apache Flink.
> > > >>>
> > > >>> The current Flink CDC code, documentation, and website can be
> > > >>> found here:
> > > >>> code: https://github.com/ververica/flink-cdc-connectors <
> > > >>> https://github.com/ververica/flink-cdc-connectors>
> > > >>> docs: https://ververica.github.io/flink-cdc-connectors/ <
> > > >>> https://ververica.github.io/flink-cdc-connectors/>
> > > >>>
> > > >>> This vote should capture whether the Apache Flink community is
> > > > interested
> > > >>> in accepting, maintaining, and evolving Flink CDC.
> > > >>>
> > > >>> Regarding my original proposal[1] in the dev mailing list, I
> > firmly
> > > >> believe
> > > >>> that this initiative aligns perfectly with Flink. For the Flink
> > > >> community,
> > > >>> it represents an opportunity to bolster Flink's competitive
> edge
> > in
> > > >>> streaming
> > > >>> data integration, fostering the robust growth and prosperity of
> > the
> > > >> Apache
> > > >>> Flink
> > > >>> ecosystem. For the Flink CDC project, becoming a sub-project of
> > >  Apache
> > > >>> Flink
> > > >>> means becoming an integral part of a neutral open-source
> > community,
> > > >>> capable of
> > > >>> attracting a more diverse pool of contributors.
> > > >>>
> > > >>> All Flink CDC maintainers are dedicated to continuously
> > > >>> contributing
> > >  to
> > > >>> achieve
> > > >>> seamless integration with Flink. Additionally, PMC members like
> > > >>> Jark,
> > > >>> Qingsheng,
> > > >>> and I are willing to infacilitate the expansion of contributors
> > and
> > > >>> committers to
> > > >>> effectively maintain this new sub-project.
> > > >>>
> > > >>> This is a "Adoption of a new Codebase" vote as per the Flink
> > bylaws
> > > > [2].
> > > >>> Only PMC votes are binding. The vote will be open at least 7
> days
> > > >>> (excluding weekends), meaning until Thursday January 18 12:00
> > UTC,
> > > >>> or
> > > >>> until we
> > > >>> achieve the 2/3rd majority. We will follow the instructions in
> > the
> > > > Flink
> > > >>> Bylaws
> > > >>> in the case of insufficient active binding voters:
> > > >>>
> > >  1. Wait until the minimum length of the voting passes.
> > >  2. Publicly reach out via personal email to the remaining
> > binding
> > > >> voters
> > > >>> in the
> > > >>> voting mail thread for at least 2 attempts with at least 7 days
> > >  between
> > > >>> two attempts.
> > >  3. If the binding voter being contacted still failed to
> respond
> > >  after
> > > >>> all the attempts,
> > > >>> the binding voter will be considered as inactive for the
> purpose
> > of
> > > > this
> > > >>> particular voting.
> > > >>>
> > > >>> Welcome voting !
> > > >>>
> > > >>> Best,
> > > >>> Leonard
> > > >>> [1]
> > > >>> https://lists.apache.org/thread/o7klnbsotmmql999bnwmdgo56b6kxx9l
> > > >>> [2]
> > > >>>
> > > >>
> > > >
> > > 
> > > >>>
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026
> > > >>
> > > >
> > > 
> > > >>>
> > >
> > >
> >
>

Re: [VOTE] Accept Flink CDC into Apache Flink

[Danny Cranmer]

+1 (binding)

Thanks,
Danny

On Tue, Jan 9, 2024 at 9:31 AM Feng Jin  wrote:

> +1 (non-binding)
>
> Best,
> Feng Jin
>
> On Tue, Jan 9, 2024 at 5:29 PM Yuxin Tan  wrote:
>
> > +1 (non-binding)
> >
> > Best,
> > Yuxin
> >
> >
> > Márton Balassi  于2024年1月9日周二 17:25写道：
> >
> > > +1 (binding)
> > >
> > > On Tue, Jan 9, 2024 at 10:15 AM Leonard Xu  wrote:
> > >
> > > > +1(binding)
> > > >
> > > > Best,
> > > > Leonard
> > > >
> > > > > 2024年1月9日 下午5:08，Yangze Guo  写道：
> > > > >
> > > > > +1 (non-binding)
> > > > >
> > > > > Best,
> > > > > Yangze Guo
> > > > >
> > > > > On Tue, Jan 9, 2024 at 5:06 PM Robert Metzger  >
> > > > wrote:
> > > > >>
> > > > >> +1 (binding)
> > > > >>
> > > > >>
> > > > >> On Tue, Jan 9, 2024 at 9:54 AM Guowei Ma 
> > > wrote:
> > > > >>
> > > > >>> +1 (binding)
> > > > >>> Best,
> > > > >>> Guowei
> > > > >>>
> > > > >>>
> > > > >>> On Tue, Jan 9, 2024 at 4:49 PM Rui Fan <1996fan...@gmail.com>
> > wrote:
> > > > >>>
> > > >  +1 (non-binding)
> > > > 
> > > >  Best,
> > > >  Rui
> > > > 
> > > >  On Tue, Jan 9, 2024 at 4:41 PM Hang Ruan <
> ruanhang1...@gmail.com>
> > > > wrote:
> > > > 
> > > > > +1 (non-binding)
> > > > >
> > > > > Best,
> > > > > Hang
> > > > >
> > > > > gongzhongqiang  于2024年1月9日周二
> 16:25写道：
> > > > >
> > > > >> +1 non-binding
> > > > >>
> > > > >> Best,
> > > > >> Zhongqiang
> > > > >>
> > > > >> Leonard Xu  于2024年1月9日周二 15:05写道：
> > > > >>
> > > > >>> Hello all,
> > > > >>>
> > > > >>> This is the official vote whether to accept the Flink CDC
> code
> > > > >> contribution
> > > > >>> to Apache Flink.
> > > > >>>
> > > > >>> The current Flink CDC code, documentation, and website can be
> > > > >>> found here:
> > > > >>> code: https://github.com/ververica/flink-cdc-connectors <
> > > > >>> https://github.com/ververica/flink-cdc-connectors>
> > > > >>> docs: https://ververica.github.io/flink-cdc-connectors/ <
> > > > >>> https://ververica.github.io/flink-cdc-connectors/>
> > > > >>>
> > > > >>> This vote should capture whether the Apache Flink community
> is
> > > > > interested
> > > > >>> in accepting, maintaining, and evolving Flink CDC.
> > > > >>>
> > > > >>> Regarding my original proposal[1] in the dev mailing list, I
> > > firmly
> > > > >> believe
> > > > >>> that this initiative aligns perfectly with Flink. For the
> Flink
> > > > >> community,
> > > > >>> it represents an opportunity to bolster Flink's competitive
> > edge
> > > in
> > > > >>> streaming
> > > > >>> data integration, fostering the robust growth and prosperity
> of
> > > the
> > > > >> Apache
> > > > >>> Flink
> > > > >>> ecosystem. For the Flink CDC project, becoming a sub-project
> of
> > > >  Apache
> > > > >>> Flink
> > > > >>> means becoming an integral part of a neutral open-source
> > > community,
> > > > >>> capable of
> > > > >>> attracting a more diverse pool of contributors.
> > > > >>>
> > > > >>> All Flink CDC maintainers are dedicated to continuously
> > > > >>> contributing
> > > >  to
> > > > >>> achieve
> > > > >>> seamless integration with Flink. Additionally, PMC members
> like
> > > > >>> Jark,
> > > > >>> Qingsheng,
> > > > >>> and I are willing to infacilitate the expansion of
> contributors
> > > and
> > > > >>> committers to
> > > > >>> effectively maintain this new sub-project.
> > > > >>>
> > > > >>> This is a "Adoption of a new Codebase" vote as per the Flink
> > > bylaws
> > > > > [2].
> > > > >>> Only PMC votes are binding. The vote will be open at least 7
> > days
> > > > >>> (excluding weekends), meaning until Thursday January 18 12:00
> > > UTC,
> > > > >>> or
> > > > >>> until we
> > > > >>> achieve the 2/3rd majority. We will follow the instructions
> in
> > > the
> > > > > Flink
> > > > >>> Bylaws
> > > > >>> in the case of insufficient active binding voters:
> > > > >>>
> > > >  1. Wait until the minimum length of the voting passes.
> > > >  2. Publicly reach out via personal email to the remaining
> > > binding
> > > > >> voters
> > > > >>> in the
> > > > >>> voting mail thread for at least 2 attempts with at least 7
> days
> > > >  between
> > > > >>> two attempts.
> > > >  3. If the binding voter being contacted still failed to
> > respond
> > > >  after
> > > > >>> all the attempts,
> > > > >>> the binding voter will be considered as inactive for the
> > purpose
> > > of
> > > > > this
> > > > >>> particular voting.
> > > > >>>
> > > > >>> Welcome voting !
> > > > >>>
> > > > >>> Best,
> > > > >>> Leonard
> > > > >>> [1]
> > > > >>> https://lists.apache.org/thread/o7klnbsotmmql999bnwmdgo56b6kxx9l
> > > > >>> [2]
> > > > >>>
> > > > >>
> > > > >
> > > > 
>

Re: [VOTE] Accept Flink CDC into Apache Flink

[xiangyu feng]

+1 (non-binding)

Regards,
Xiangyu Feng

Danny Cranmer  于2024年1月9日周二 17:50写道：

> +1 (binding)
>
> Thanks,
> Danny
>
> On Tue, Jan 9, 2024 at 9:31 AM Feng Jin  wrote:
>
> > +1 (non-binding)
> >
> > Best,
> > Feng Jin
> >
> > On Tue, Jan 9, 2024 at 5:29 PM Yuxin Tan  wrote:
> >
> > > +1 (non-binding)
> > >
> > > Best,
> > > Yuxin
> > >
> > >
> > > Márton Balassi  于2024年1月9日周二 17:25写道：
> > >
> > > > +1 (binding)
> > > >
> > > > On Tue, Jan 9, 2024 at 10:15 AM Leonard Xu 
> wrote:
> > > >
> > > > > +1(binding)
> > > > >
> > > > > Best,
> > > > > Leonard
> > > > >
> > > > > > 2024年1月9日 下午5:08，Yangze Guo  写道：
> > > > > >
> > > > > > +1 (non-binding)
> > > > > >
> > > > > > Best,
> > > > > > Yangze Guo
> > > > > >
> > > > > > On Tue, Jan 9, 2024 at 5:06 PM Robert Metzger <
> rmetz...@apache.org
> > >
> > > > > wrote:
> > > > > >>
> > > > > >> +1 (binding)
> > > > > >>
> > > > > >>
> > > > > >> On Tue, Jan 9, 2024 at 9:54 AM Guowei Ma 
> > > > wrote:
> > > > > >>
> > > > > >>> +1 (binding)
> > > > > >>> Best,
> > > > > >>> Guowei
> > > > > >>>
> > > > > >>>
> > > > > >>> On Tue, Jan 9, 2024 at 4:49 PM Rui Fan <1996fan...@gmail.com>
> > > wrote:
> > > > > >>>
> > > > >  +1 (non-binding)
> > > > > 
> > > > >  Best,
> > > > >  Rui
> > > > > 
> > > > >  On Tue, Jan 9, 2024 at 4:41 PM Hang Ruan <
> > ruanhang1...@gmail.com>
> > > > > wrote:
> > > > > 
> > > > > > +1 (non-binding)
> > > > > >
> > > > > > Best,
> > > > > > Hang
> > > > > >
> > > > > > gongzhongqiang  于2024年1月9日周二
> > 16:25写道：
> > > > > >
> > > > > >> +1 non-binding
> > > > > >>
> > > > > >> Best,
> > > > > >> Zhongqiang
> > > > > >>
> > > > > >> Leonard Xu  于2024年1月9日周二 15:05写道：
> > > > > >>
> > > > > >>> Hello all,
> > > > > >>>
> > > > > >>> This is the official vote whether to accept the Flink CDC
> > code
> > > > > >> contribution
> > > > > >>> to Apache Flink.
> > > > > >>>
> > > > > >>> The current Flink CDC code, documentation, and website can
> be
> > > > > >>> found here:
> > > > > >>> code: https://github.com/ververica/flink-cdc-connectors <
> > > > > >>> https://github.com/ververica/flink-cdc-connectors>
> > > > > >>> docs: https://ververica.github.io/flink-cdc-connectors/ <
> > > > > >>> https://ververica.github.io/flink-cdc-connectors/>
> > > > > >>>
> > > > > >>> This vote should capture whether the Apache Flink community
> > is
> > > > > > interested
> > > > > >>> in accepting, maintaining, and evolving Flink CDC.
> > > > > >>>
> > > > > >>> Regarding my original proposal[1] in the dev mailing list,
> I
> > > > firmly
> > > > > >> believe
> > > > > >>> that this initiative aligns perfectly with Flink. For the
> > Flink
> > > > > >> community,
> > > > > >>> it represents an opportunity to bolster Flink's competitive
> > > edge
> > > > in
> > > > > >>> streaming
> > > > > >>> data integration, fostering the robust growth and
> prosperity
> > of
> > > > the
> > > > > >> Apache
> > > > > >>> Flink
> > > > > >>> ecosystem. For the Flink CDC project, becoming a
> sub-project
> > of
> > > > >  Apache
> > > > > >>> Flink
> > > > > >>> means becoming an integral part of a neutral open-source
> > > > community,
> > > > > >>> capable of
> > > > > >>> attracting a more diverse pool of contributors.
> > > > > >>>
> > > > > >>> All Flink CDC maintainers are dedicated to continuously
> > > > > >>> contributing
> > > > >  to
> > > > > >>> achieve
> > > > > >>> seamless integration with Flink. Additionally, PMC members
> > like
> > > > > >>> Jark,
> > > > > >>> Qingsheng,
> > > > > >>> and I are willing to infacilitate the expansion of
> > contributors
> > > > and
> > > > > >>> committers to
> > > > > >>> effectively maintain this new sub-project.
> > > > > >>>
> > > > > >>> This is a "Adoption of a new Codebase" vote as per the
> Flink
> > > > bylaws
> > > > > > [2].
> > > > > >>> Only PMC votes are binding. The vote will be open at least
> 7
> > > days
> > > > > >>> (excluding weekends), meaning until Thursday January 18
> 12:00
> > > > UTC,
> > > > > >>> or
> > > > > >>> until we
> > > > > >>> achieve the 2/3rd majority. We will follow the instructions
> > in
> > > > the
> > > > > > Flink
> > > > > >>> Bylaws
> > > > > >>> in the case of insufficient active binding voters:
> > > > > >>>
> > > > >  1. Wait until the minimum length of the voting passes.
> > > > >  2. Publicly reach out via personal email to the remaining
> > > > binding
> > > > > >> voters
> > > > > >>> in the
> > > > > >>> voting mail thread for at least 2 attempts with at least 7
> > days
> > > > >  between
> > > > > >>> two attempts.
> > > > >  3. If the binding voter being contacted still failed to
> > > respond
> > > > >  after
> > > > > >>> all 

[jira] [Created] (FLINK-34041) Fix typo in docs/content/docs/deployment/ha/overview.md

[Sumin Kim (Jira)]

Sumin Kim created FLINK-34041:
-

 Summary: Fix typo in docs/content/docs/deployment/ha/overview.md
 Key: FLINK-34041
 URL: https://issues.apache.org/jira/browse/FLINK-34041
 Project: Flink
  Issue Type: Improvement
Reporter: Sumin Kim
 Attachments: image-2024-01-09-20-17-09-097.png

There is typo error in docs/content/docs/deployment/ha/overview.md
Leader election x => Leader selection



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

RE: Re: [VOTE] Accept Flink CDC into Apache Flink

[Jiabao Sun]

+1 (non-binding)

Best,
Jiabao


On 2024/01/09 09:58:04 xiangyu feng wrote:
> +1 (non-binding)
> 
> Regards,
> Xiangyu Feng
> 
> Danny Cranmer  于2024年1月9日周二 17:50写道：
> 
> > +1 (binding)
> >
> > Thanks,
> > Danny
> >
> > On Tue, Jan 9, 2024 at 9:31 AM Feng Jin  wrote:
> >
> > > +1 (non-binding)
> > >
> > > Best,
> > > Feng Jin
> > >
> > > On Tue, Jan 9, 2024 at 5:29 PM Yuxin Tan  wrote:
> > >
> > > > +1 (non-binding)
> > > >
> > > > Best,
> > > > Yuxin
> > > >
> > > >
> > > > Márton Balassi  于2024年1月9日周二 17:25写道：
> > > >
> > > > > +1 (binding)
> > > > >
> > > > > On Tue, Jan 9, 2024 at 10:15 AM Leonard Xu 
> > wrote:
> > > > >
> > > > > > +1(binding)
> > > > > >
> > > > > > Best,
> > > > > > Leonard
> > > > > >
> > > > > > > 2024年1月9日 下午5:08，Yangze Guo  写道：
> > > > > > >
> > > > > > > +1 (non-binding)
> > > > > > >
> > > > > > > Best,
> > > > > > > Yangze Guo
> > > > > > >
> > > > > > > On Tue, Jan 9, 2024 at 5:06 PM Robert Metzger <
> > rmetz...@apache.org
> > > >
> > > > > > wrote:
> > > > > > >>
> > > > > > >> +1 (binding)
> > > > > > >>
> > > > > > >>
> > > > > > >> On Tue, Jan 9, 2024 at 9:54 AM Guowei Ma 
> > > > > wrote:
> > > > > > >>
> > > > > > >>> +1 (binding)
> > > > > > >>> Best,
> > > > > > >>> Guowei
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> On Tue, Jan 9, 2024 at 4:49 PM Rui Fan <19...@gmail.com>
> > > > wrote:
> > > > > > >>>
> > > > > >  +1 (non-binding)
> > > > > > 
> > > > > >  Best,
> > > > > >  Rui
> > > > > > 
> > > > > >  On Tue, Jan 9, 2024 at 4:41 PM Hang Ruan <
> > > ruanhang1...@gmail.com>
> > > > > > wrote:
> > > > > > 
> > > > > > > +1 (non-binding)
> > > > > > >
> > > > > > > Best,
> > > > > > > Hang
> > > > > > >
> > > > > > > gongzhongqiang  于2024年1月9日周二
> > > 16:25写道：
> > > > > > >
> > > > > > >> +1 non-binding
> > > > > > >>
> > > > > > >> Best,
> > > > > > >> Zhongqiang
> > > > > > >>
> > > > > > >> Leonard Xu  于2024年1月9日周二 15:05写道：
> > > > > > >>
> > > > > > >>> Hello all,
> > > > > > >>>
> > > > > > >>> This is the official vote whether to accept the Flink CDC
> > > code
> > > > > > >> contribution
> > > > > > >>> to Apache Flink.
> > > > > > >>>
> > > > > > >>> The current Flink CDC code, documentation, and website can
> > be
> > > > > > >>> found here:
> > > > > > >>> code: https://github.com/ververica/flink-cdc-connectors <
> > > > > > >>> https://github.com/ververica/flink-cdc-connectors>
> > > > > > >>> docs: https://ververica.github.io/flink-cdc-connectors/ <
> > > > > > >>> https://ververica.github.io/flink-cdc-connectors/>
> > > > > > >>>
> > > > > > >>> This vote should capture whether the Apache Flink community
> > > is
> > > > > > > interested
> > > > > > >>> in accepting, maintaining, and evolving Flink CDC.
> > > > > > >>>
> > > > > > >>> Regarding my original proposal[1] in the dev mailing list,
> > I
> > > > > firmly
> > > > > > >> believe
> > > > > > >>> that this initiative aligns perfectly with Flink. For the
> > > Flink
> > > > > > >> community,
> > > > > > >>> it represents an opportunity to bolster Flink's competitive
> > > > edge
> > > > > in
> > > > > > >>> streaming
> > > > > > >>> data integration, fostering the robust growth and
> > prosperity
> > > of
> > > > > the
> > > > > > >> Apache
> > > > > > >>> Flink
> > > > > > >>> ecosystem. For the Flink CDC project, becoming a
> > sub-project
> > > of
> > > > > >  Apache
> > > > > > >>> Flink
> > > > > > >>> means becoming an integral part of a neutral open-source
> > > > > community,
> > > > > > >>> capable of
> > > > > > >>> attracting a more diverse pool of contributors.
> > > > > > >>>
> > > > > > >>> All Flink CDC maintainers are dedicated to continuously
> > > > > > >>> contributing
> > > > > >  to
> > > > > > >>> achieve
> > > > > > >>> seamless integration with Flink. Additionally, PMC members
> > > like
> > > > > > >>> Jark,
> > > > > > >>> Qingsheng,
> > > > > > >>> and I are willing to infacilitate the expansion of
> > > contributors
> > > > > and
> > > > > > >>> committers to
> > > > > > >>> effectively maintain this new sub-project.
> > > > > > >>>
> > > > > > >>> This is a "Adoption of a new Codebase" vote as per the
> > Flink
> > > > > bylaws
> > > > > > > [2].
> > > > > > >>> Only PMC votes are binding. The vote will be open at least
> > 7
> > > > days
> > > > > > >>> (excluding weekends), meaning until Thursday January 18
> > 12:00
> > > > > UTC,
> > > > > > >>> or
> > > > > > >>> until we
> > > > > > >>> achieve the 2/3rd majority. We will follow the instructions
> > > in
> > > > > the
> > > > > > > Flink
> > > > > > >>> Bylaws
> > > > > > >>> in the case of insufficient active binding voters:
> > > > > > >>>
> > > > > >  1. Wait until the minimum length of the voting passes.
> > 

[VOTE] FLIP-377: Support fine-grained configuration to control filter push down for Table/SQL Sources

[Jiabao Sun]

Hi Devs,

I'd like to start a vote on FLIP-377: Support fine-grained configuration to 
control filter push down for Table/SQL Sources[1] 
which has been discussed in this thread[2].

The vote will be open for at least 72 hours unless there is an objection or not 
enough votes.

[1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=276105768
[2] https://lists.apache.org/thread/nvxx8sp9jm009yywm075hoffr632tm7j

Best,
Jiabao

Re: [DISCUSS] Externalized Python Connector Release/Dependency Process

[Xingbo Huang]

Hi Danny,

+1

Thanks a lot for investigating this. Let me share the current code
management and release situation of pyflink here. I hope it will be helpful
to you.

Since Flink 1.13, release managers need to release two python packages to
pypi, apache-flink[1] and apache-flink-libraries[2]. apache-flink contains
all pyflink python code and apache-flink-libraries contains the jar package
corresponding to flink binary. The reason why the content of
apache-flink-libaries is not put into apache-flink is because starting from
Flink 1.11, pyflink provides different python versions and platform wheel
packages. If all wheel packages contain these jar packages, the space of
apache-flink will quickly increase, but pypi's project space is limited(I
applied to expand apache-flink twice), so in 1.13, I move the corresponding
jar package from apache-flink to an independent apache-flink-libraries
package.

Since each apache-connector wheel package today is shared by the platform,
we do not need to publish a corresponding apache-libraries package for a
connector currently, but we still need to package the corresponding jar of
the connector into the corresponding apche-connector pypi package.

[1] https://pypi.org/project/apache-flink/
[2] https://pypi.org/project/apache-flink-libraries/

Best,
Xingbo

Leonard Xu  于2024年1月9日周二 13:46写道：

> +1
>
> Thanks Danny for driving this.
>
> Best,
> Leonard
>
>
> > 2024年1月9日 上午2:01，Márton Balassi  写道：
> >
> > +1
> >
> > Thanks, Danny - I really appreciate you taking the time for the in-depth
> > investigation. Please proceed, looking forward to your experience.
> >
> > On Mon, Jan 8, 2024 at 6:04 PM Martijn Visser 
> > wrote:
> >
> >> Thanks for investigating Danny. It looks like the best direction to go
> to
> >> :)
> >>
> >> On Mon, Jan 8, 2024 at 5:56 PM Péter Váry 
> >> wrote:
> >>>
> >>> Thanks Danny for working on this!
> >>>
> >>> It would be good to do this in a way that the different connectors
> could
> >>> reuse as much code as possible, so if possible put most of the code to
> >> the
> >>> flink connector shared utils repo [1]
> >>>
> >>> +1 from for the general direction (non-binding)
> >>>
> >>> Thanks,
> >>> Peter
> >>>
> >>> [1] https://github.com/apache/flink-connector-shared-utils
> >>>
> >>>
> >>> Danny Cranmer  ezt írta (időpont: 2024. jan.
> >> 8.,
> >>> H, 17:31):
> >>>
>  Hello all,
> 
>  I have been working with Péter and Marton on externalizing python
>  connectors [1] from the main repo to the connector repositories. We
> >> have
>  the code moved and the CI running tests for Kafka and AWS Connectors.
> >> I am
>  now looking into the release process.
> 
>  When we undertake a Flink release we perform the following steps [2],
>  regarding Python: 1/ run python build on CI, 2/ download Wheels
> >> artifacts,
>  3/ upload artifacts to the dist and 4/ deploy to pypi. The plan is to
>  follow the same steps for connectors, using Github actions instead of
> >> Azure
>  pipeline.
> 
>  Today we have a single pypi project for pyflink that contains all the
> >> Flink
>  libs, apache-flink [3]. I propose we create a new pypi project per
>  connector using the existing connector version, and following naming
>  convention: apache-, for example:
>  apache-flink-connector-aws, apache-flink-connector-kafka. Therefore to
> >> use
>  a DataStream API connector in python, users would need to first
> >> install the
>  lib, for example "python -m pip install apache-flink-connector-aws".
> 
>  Once we have consensus I will update the release process and perform a
>  release of the flink-connector-aws project to test it end-to-end. I
> >> look
>  forward to any feedback.
> 
>  Thanks,
>  Danny
> 
>  [1] https://issues.apache.org/jira/browse/FLINK-33528
>  [2]
> 
> >>
> https://cwiki.apache.org/confluence/display/FLINK/Creating+a+Flink+Release
>  [3] https://pypi.org/project/apache-flink/
> 
> >>
>
>

Re: [DISCUSS] FLIP-403: High Availability Services for OLAP Scenarios

[Zhu Zhu]

> I would treat refactoring as a technical debt...

Sorry I don't quite get the needs of the refactoring work.

The refactoring work brings benefits if there are requirements to combine
different leader election services and persistence services.
The answer in this FLIP is to combine DefaultLeaderServices and
EmbeddedPersistenceServices. But I'm concerned that, if the goal is to
avoid the cost of job recovery, disable the persistence of the overall
cluster might be an overkill. e.g. if later we want the cluster partitions
to be recovered after JM failover?

Yet I do not think of the needs of other new combinations at the moment,
e.g. a non-HA leader election service with an HA persistence service,
a ZK leader election service with a K8s persistence service. Maybe you
have some good cases for it?

TBH, the current class structure looks simpler to me. I'm also wondering
whether it's possible to merge StandaloneHaServices with EmbeddedHaServices,
because the latter one is a special case(all components in the same process)
of the former one.

> it still involves creating a znode or writing to the configmap
for each job

Is it possible to avoid the cost? My gut feeling is that these actions
are not necessary after Flink does leader election for the overall master
process.

> such as checkpoint and blob storage except for the job graph store

How about disabling the checkpoint to avoid the cost? I know the cost is
there
even if we disable the checkpoint at the moment. But I think it can be
fixed.
Checkpoint is not needed if job recovery is not needed, the concepts are
highly related.

Regarding blob storage, I'm not sure whether it's good to disable HA for it.
If HA is disabled, the jobmanager needs to directly participate in all blob
shipping work which may result in a hot-spot.

WDYT?

Thanks,
Zhu

Yangze Guo  于2024年1月9日周二 10:55写道：

> Thank you for your comments, Zhu!
>
> 1. I would treat refactoring as a technical debt and a side effect of
> this FLIP. The idea is inspired by Matthias' comments in [1]. It
> suggests having a single implementation of HighAvailabilityServices
> that requires a factory method for persistence services and leader
> services. After this, we will achieve a clearer class hierarchy for
> HAServices and eliminate code duplication.
>
> 2. While FLINK-24038 does eliminate the leader election time cost for
> each job, it still involves creating a znode or writing to the
> configmap for each job, which can negatively impact performance under
> higher workloads. This also applies to all other persistence services
> such as checkpoint and blob storage except for the job graph store.
>
> WDYT?
>
> [1]
> https://issues.apache.org/jira/browse/FLINK-31816?focusedCommentId=17741054&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17741054
>
> Best,
> Yangze Guo
>
> On Mon, Jan 8, 2024 at 7:37 PM Zhu Zhu  wrote:
> >
> > Thanks for creating the FLIP and starting the discussion, Yangze. It
> makes
> > sense to me to improve the job submission performance in OLAP scenarios.
> >
> > I have a few questions regarding the proposed changes:
> >
> > 1. How about skipping the job graph persistence if the proposed config
> > 'high-availability.enable-job-recovery' is set to false? In this way,
> > we do not need to do the refactoring work.
> >
> > 2. Instead of using different HA services for Dispatcher and JobMaster.
> > Can we leverage the work of FLINK-24038 to eliminate the leader election
> > time cost of each job? Honestly I had thought it was already the truth
> but
> > seems it is not. This improvement can also benefit non-OLAP jobs.
> >
> > Thanks,
> > Zhu
> >
> > Yangze Guo  于2024年1月8日周一 17:11写道：
> >
> > > Thanks for the pointer, Rui!
> > >
> > > I have reviewed FLIP-383, and based on my understanding, this feature
> > > should be enabled by default for batch jobs in the future. Therefore,
> > > +1 for checking the parameters and issuing log warnings when the user
> > > explicitly configures execution.batch.job-recovery.enabled to true.
> > >
> > > +1 for high-availability.job-recovery.enabled, which would be more
> > > suitable with YAML hierarchy.
> > >
> > >
> > > Best,
> > > Yangze Guo
> > >
> > > On Mon, Jan 8, 2024 at 3:43 PM Rui Fan <1996fan...@gmail.com> wrote:
> > > >
> > > > Thanks to Yangze driving this proposal!
> > > >
> > > > Overall looks good to me! This proposal is useful for
> > > > the performance when the job doesn't need the failover.
> > > >
> > > > I have some minor questions:
> > > >
> > > > 1. How does it work with FLIP-383[1]?
> > > >
> > > > This FLIP introduces a high-availability.enable-job-recovery,
> > > > and FLIP-383 introduces a execution.batch.job-recovery.enabled.
> > > >
> > > > IIUC, when high-availability.enable-job-recovery is false, the job
> > > > cannot recover even if execution.batch.job-recovery.enabled = true,
> > > > right?
> > > >
> > > > If so, could we check some parameters and warn some logs? Or
> > > > disable the ex

Re: Re: [VOTE] Accept Flink CDC into Apache Flink

[Lijie Wang]

+1 (non-binding)

Best,
Lijie

Jiabao Sun  于2024年1月9日周二 19:28写道：

> +1 (non-binding)
>
> Best,
> Jiabao
>
>
> On 2024/01/09 09:58:04 xiangyu feng wrote:
> > +1 (non-binding)
> >
> > Regards,
> > Xiangyu Feng
> >
> > Danny Cranmer  于2024年1月9日周二 17:50写道：
> >
> > > +1 (binding)
> > >
> > > Thanks,
> > > Danny
> > >
> > > On Tue, Jan 9, 2024 at 9:31 AM Feng Jin  wrote:
> > >
> > > > +1 (non-binding)
> > > >
> > > > Best,
> > > > Feng Jin
> > > >
> > > > On Tue, Jan 9, 2024 at 5:29 PM Yuxin Tan  wrote:
> > > >
> > > > > +1 (non-binding)
> > > > >
> > > > > Best,
> > > > > Yuxin
> > > > >
> > > > >
> > > > > Márton Balassi  于2024年1月9日周二 17:25写道：
> > > > >
> > > > > > +1 (binding)
> > > > > >
> > > > > > On Tue, Jan 9, 2024 at 10:15 AM Leonard Xu 
> > > wrote:
> > > > > >
> > > > > > > +1(binding)
> > > > > > >
> > > > > > > Best,
> > > > > > > Leonard
> > > > > > >
> > > > > > > > 2024年1月9日 下午5:08，Yangze Guo  写道：
> > > > > > > >
> > > > > > > > +1 (non-binding)
> > > > > > > >
> > > > > > > > Best,
> > > > > > > > Yangze Guo
> > > > > > > >
> > > > > > > > On Tue, Jan 9, 2024 at 5:06 PM Robert Metzger <
> > > rmetz...@apache.org
> > > > >
> > > > > > > wrote:
> > > > > > > >>
> > > > > > > >> +1 (binding)
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> On Tue, Jan 9, 2024 at 9:54 AM Guowei Ma 
> > > > > > wrote:
> > > > > > > >>
> > > > > > > >>> +1 (binding)
> > > > > > > >>> Best,
> > > > > > > >>> Guowei
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>> On Tue, Jan 9, 2024 at 4:49 PM Rui Fan <19...@gmail.com>
> > > > > wrote:
> > > > > > > >>>
> > > > > > >  +1 (non-binding)
> > > > > > > 
> > > > > > >  Best,
> > > > > > >  Rui
> > > > > > > 
> > > > > > >  On Tue, Jan 9, 2024 at 4:41 PM Hang Ruan <
> > > > ruanhang1...@gmail.com>
> > > > > > > wrote:
> > > > > > > 
> > > > > > > > +1 (non-binding)
> > > > > > > >
> > > > > > > > Best,
> > > > > > > > Hang
> > > > > > > >
> > > > > > > > gongzhongqiang  于2024年1月9日周二
> > > > 16:25写道：
> > > > > > > >
> > > > > > > >> +1 non-binding
> > > > > > > >>
> > > > > > > >> Best,
> > > > > > > >> Zhongqiang
> > > > > > > >>
> > > > > > > >> Leonard Xu  于2024年1月9日周二 15:05写道：
> > > > > > > >>
> > > > > > > >>> Hello all,
> > > > > > > >>>
> > > > > > > >>> This is the official vote whether to accept the Flink
> CDC
> > > > code
> > > > > > > >> contribution
> > > > > > > >>> to Apache Flink.
> > > > > > > >>>
> > > > > > > >>> The current Flink CDC code, documentation, and website
> can
> > > be
> > > > > > > >>> found here:
> > > > > > > >>> code:
> https://github.com/ververica/flink-cdc-connectors <
> > > > > > > >>> https://github.com/ververica/flink-cdc-connectors>
> > > > > > > >>> docs:
> https://ververica.github.io/flink-cdc-connectors/ <
> > > > > > > >>> https://ververica.github.io/flink-cdc-connectors/>
> > > > > > > >>>
> > > > > > > >>> This vote should capture whether the Apache Flink
> community
> > > > is
> > > > > > > > interested
> > > > > > > >>> in accepting, maintaining, and evolving Flink CDC.
> > > > > > > >>>
> > > > > > > >>> Regarding my original proposal[1] in the dev mailing
> list,
> > > I
> > > > > > firmly
> > > > > > > >> believe
> > > > > > > >>> that this initiative aligns perfectly with Flink. For
> the
> > > > Flink
> > > > > > > >> community,
> > > > > > > >>> it represents an opportunity to bolster Flink's
> competitive
> > > > > edge
> > > > > > in
> > > > > > > >>> streaming
> > > > > > > >>> data integration, fostering the robust growth and
> > > prosperity
> > > > of
> > > > > > the
> > > > > > > >> Apache
> > > > > > > >>> Flink
> > > > > > > >>> ecosystem. For the Flink CDC project, becoming a
> > > sub-project
> > > > of
> > > > > > >  Apache
> > > > > > > >>> Flink
> > > > > > > >>> means becoming an integral part of a neutral
> open-source
> > > > > > community,
> > > > > > > >>> capable of
> > > > > > > >>> attracting a more diverse pool of contributors.
> > > > > > > >>>
> > > > > > > >>> All Flink CDC maintainers are dedicated to continuously
> > > > > > > >>> contributing
> > > > > > >  to
> > > > > > > >>> achieve
> > > > > > > >>> seamless integration with Flink. Additionally, PMC
> members
> > > > like
> > > > > > > >>> Jark,
> > > > > > > >>> Qingsheng,
> > > > > > > >>> and I are willing to infacilitate the expansion of
> > > > contributors
> > > > > > and
> > > > > > > >>> committers to
> > > > > > > >>> effectively maintain this new sub-project.
> > > > > > > >>>
> > > > > > > >>> This is a "Adoption of a new Codebase" vote as per the
> > > Flink
> > > > > > bylaws
> > > > > > > > [2].
> > > > > > > >>> Only PMC votes are binding. The vote will be open at
> least
> > > 7
> > > > > days
> > > > > > > >>> (excluding weekends), meaning until Thursd

Re: Re: [VOTE] Accept Flink CDC into Apache Flink

[Jane Chan]

+1 (non-binding)

Best,
Jane

On Tue, Jan 9, 2024 at 8:41 PM Lijie Wang  wrote:

> +1 (non-binding)
>
> Best,
> Lijie
>
> Jiabao Sun  于2024年1月9日周二 19:28写道：
>
> > +1 (non-binding)
> >
> > Best,
> > Jiabao
> >
> >
> > On 2024/01/09 09:58:04 xiangyu feng wrote:
> > > +1 (non-binding)
> > >
> > > Regards,
> > > Xiangyu Feng
> > >
> > > Danny Cranmer  于2024年1月9日周二 17:50写道：
> > >
> > > > +1 (binding)
> > > >
> > > > Thanks,
> > > > Danny
> > > >
> > > > On Tue, Jan 9, 2024 at 9:31 AM Feng Jin  wrote:
> > > >
> > > > > +1 (non-binding)
> > > > >
> > > > > Best,
> > > > > Feng Jin
> > > > >
> > > > > On Tue, Jan 9, 2024 at 5:29 PM Yuxin Tan  wrote:
> > > > >
> > > > > > +1 (non-binding)
> > > > > >
> > > > > > Best,
> > > > > > Yuxin
> > > > > >
> > > > > >
> > > > > > Márton Balassi  于2024年1月9日周二 17:25写道：
> > > > > >
> > > > > > > +1 (binding)
> > > > > > >
> > > > > > > On Tue, Jan 9, 2024 at 10:15 AM Leonard Xu 
> > > > wrote:
> > > > > > >
> > > > > > > > +1(binding)
> > > > > > > >
> > > > > > > > Best,
> > > > > > > > Leonard
> > > > > > > >
> > > > > > > > > 2024年1月9日 下午5:08，Yangze Guo  写道：
> > > > > > > > >
> > > > > > > > > +1 (non-binding)
> > > > > > > > >
> > > > > > > > > Best,
> > > > > > > > > Yangze Guo
> > > > > > > > >
> > > > > > > > > On Tue, Jan 9, 2024 at 5:06 PM Robert Metzger <
> > > > rmetz...@apache.org
> > > > > >
> > > > > > > > wrote:
> > > > > > > > >>
> > > > > > > > >> +1 (binding)
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> On Tue, Jan 9, 2024 at 9:54 AM Guowei Ma  >
> > > > > > > wrote:
> > > > > > > > >>
> > > > > > > > >>> +1 (binding)
> > > > > > > > >>> Best,
> > > > > > > > >>> Guowei
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>> On Tue, Jan 9, 2024 at 4:49 PM Rui Fan <19...@gmail.com>
> > > > > > wrote:
> > > > > > > > >>>
> > > > > > > >  +1 (non-binding)
> > > > > > > > 
> > > > > > > >  Best,
> > > > > > > >  Rui
> > > > > > > > 
> > > > > > > >  On Tue, Jan 9, 2024 at 4:41 PM Hang Ruan <
> > > > > ruanhang1...@gmail.com>
> > > > > > > > wrote:
> > > > > > > > 
> > > > > > > > > +1 (non-binding)
> > > > > > > > >
> > > > > > > > > Best,
> > > > > > > > > Hang
> > > > > > > > >
> > > > > > > > > gongzhongqiang  于2024年1月9日周二
> > > > > 16:25写道：
> > > > > > > > >
> > > > > > > > >> +1 non-binding
> > > > > > > > >>
> > > > > > > > >> Best,
> > > > > > > > >> Zhongqiang
> > > > > > > > >>
> > > > > > > > >> Leonard Xu  于2024年1月9日周二 15:05写道：
> > > > > > > > >>
> > > > > > > > >>> Hello all,
> > > > > > > > >>>
> > > > > > > > >>> This is the official vote whether to accept the Flink
> > CDC
> > > > > code
> > > > > > > > >> contribution
> > > > > > > > >>> to Apache Flink.
> > > > > > > > >>>
> > > > > > > > >>> The current Flink CDC code, documentation, and
> website
> > can
> > > > be
> > > > > > > > >>> found here:
> > > > > > > > >>> code:
> > https://github.com/ververica/flink-cdc-connectors <
> > > > > > > > >>> https://github.com/ververica/flink-cdc-connectors>
> > > > > > > > >>> docs:
> > https://ververica.github.io/flink-cdc-connectors/ <
> > > > > > > > >>> https://ververica.github.io/flink-cdc-connectors/>
> > > > > > > > >>>
> > > > > > > > >>> This vote should capture whether the Apache Flink
> > community
> > > > > is
> > > > > > > > > interested
> > > > > > > > >>> in accepting, maintaining, and evolving Flink CDC.
> > > > > > > > >>>
> > > > > > > > >>> Regarding my original proposal[1] in the dev mailing
> > list,
> > > > I
> > > > > > > firmly
> > > > > > > > >> believe
> > > > > > > > >>> that this initiative aligns perfectly with Flink. For
> > the
> > > > > Flink
> > > > > > > > >> community,
> > > > > > > > >>> it represents an opportunity to bolster Flink's
> > competitive
> > > > > > edge
> > > > > > > in
> > > > > > > > >>> streaming
> > > > > > > > >>> data integration, fostering the robust growth and
> > > > prosperity
> > > > > of
> > > > > > > the
> > > > > > > > >> Apache
> > > > > > > > >>> Flink
> > > > > > > > >>> ecosystem. For the Flink CDC project, becoming a
> > > > sub-project
> > > > > of
> > > > > > > >  Apache
> > > > > > > > >>> Flink
> > > > > > > > >>> means becoming an integral part of a neutral
> > open-source
> > > > > > > community,
> > > > > > > > >>> capable of
> > > > > > > > >>> attracting a more diverse pool of contributors.
> > > > > > > > >>>
> > > > > > > > >>> All Flink CDC maintainers are dedicated to
> continuously
> > > > > > > > >>> contributing
> > > > > > > >  to
> > > > > > > > >>> achieve
> > > > > > > > >>> seamless integration with Flink. Additionally, PMC
> > members
> > > > > like
> > > > > > > > >>> Jark,
> > > > > > > > >>> Qingsheng,
> > > > > > > > >>> and I are willing to infacilitate the expansion of
> > > > > contributors
> > > > > > > and

[jira] [Created] (FLINK-34042) Update the documentation

[Peter Vary (Jira)]

Peter Vary created FLINK-34042:
--

 Summary: Update the documentation 
 Key: FLINK-34042
 URL: https://issues.apache.org/jira/browse/FLINK-34042
 Project: Flink
  Issue Type: Sub-task
Reporter: Peter Vary






--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (FLINK-34043) Remove deprecated Sink V2 interfaces

[Peter Vary (Jira)]

Peter Vary created FLINK-34043:
--

 Summary: Remove deprecated Sink V2 interfaces
 Key: FLINK-34043
 URL: https://issues.apache.org/jira/browse/FLINK-34043
 Project: Flink
  Issue Type: Sub-task
  Components: API / DataStream
Reporter: Peter Vary


In Flink 1.20.0 we should remove the interfaces deprecated by FLINK-33973



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[Jan 26 Feature Freeze][SUMMARY] Flink 1.19 Release Sync 01/09/2024

[Lincoln Lee]

Hi devs,

Happy New Year!

Here's 1st release sync summary of 1.19 in 2024!
There're less than 3 weeks until the feature freeze date(Jan 26).

- Features & issues tracking
  So far we've had 27 flips/features and 4 of which have been done.
  Contributors are encouraged to update the status of related items on 1.19
wiki page[1], including documentation and cross-team testing requirements.

- Blockers
  - [reopened] FLINK-32978 Deprecate RichFunction#open(Configuration
parameters)[2] thanks @sergy for reporting the un-released breaking change
and @Wencong will fix it soon

- Sync meeting (https://meet.google.com/vcx-arzs-trv)
  The next release sync is Jan 23, 2024. After feature freeze day, the
release sync will happen every week.
  We encourage attendees to fill out the topics to be discussed at the
bottom of 1.19 wiki page[1] a day in advance, make it easier for everyone
to understand the background of the topics.

[1] https://cwiki.apache.org/confluence/display/FLINK/1.19+Release
[2] https://issues.apache.org/jira/browse/FLINK-32978

Best,
Yun, Jing, Martijn and Lincoln

[jira] [Created] (FLINK-34044) Kinesis Sink Cannot be Created via TableDescriptor

[Tilman Krokotsch (Jira)]

Tilman Krokotsch created FLINK-34044:


 Summary: Kinesis Sink Cannot be Created via TableDescriptor
 Key: FLINK-34044
 URL: https://issues.apache.org/jira/browse/FLINK-34044
 Project: Flink
  Issue Type: Bug
  Components: Connectors / AWS
Affects Versions: aws-connector-4.2.0
Reporter: Tilman Krokotsch


When trying to create a Kinesis Stream Sink in Table API via a TableDescriptor 
I get an error:
{code:java}
Caused by: java.lang.UnsupportedOperationException
    at 
java.base/java.util.Collections$UnmodifiableMap.remove(Collections.java:1460)
    at 
org.apache.flink.connector.kinesis.table.util.KinesisStreamsConnectorOptionsUtils$KinesisProducerOptionsMapper.removeMappedOptions(KinesisStreamsConnectorOptionsUtils.java:249)
    at 
org.apache.flink.connector.kinesis.table.util.KinesisStreamsConnectorOptionsUtils$KinesisProducerOptionsMapper.mapDeprecatedClientOptions(KinesisStreamsConnectorOptionsUtils.java:158)
    at 
org.apache.flink.connector.kinesis.table.util.KinesisStreamsConnectorOptionsUtils.(KinesisStreamsConnectorOptionsUtils.java:90)
    at 
org.apache.flink.connector.kinesis.table.KinesisDynamicTableSinkFactory.createDynamicTableSink(KinesisDynamicTableSinkFactory.java:61)
    at 
org.apache.flink.table.factories.FactoryUtil.createDynamicTableSink(FactoryUtil.java:267)
    ... 20 more
{code}
Here is a minimum reproducing example with Flink-1.17.2 and 
flink-connector-kinesis-4.2.0:
{code:java}
public class Job {
  public static void main(String[] args) throws Exception {
// create data stream environment
StreamExecutionEnvironment sEnv = 
StreamExecutionEnvironment.getExecutionEnvironment();
sEnv.setRuntimeMode(RuntimeExecutionMode.STREAMING);
StreamTableEnvironment tEnv = StreamTableEnvironment.create(sEnv);

Schema a = Schema.newBuilder().column("a", DataTypes.STRING()).build();
tEnv.createTemporaryTable(
"exampleTable", 
TableDescriptor.forConnector("datagen").schema(a).build());
TableDescriptor descriptor =
TableDescriptor.forConnector("kinesis")
.schema(a)
.format("json")
.option("stream", "abc")
.option("aws.region", "eu-central-1")
.build();
tEnv.createTemporaryTable("sinkTable", descriptor);

tEnv.from("exampleTable").executeInsert("sinkTable"); // error occurs here
  }
} {code}
>From my investigation, the error is triggered by the `ResolvedCatalogTable` 
>used when re-mapping the deprecated Kinesis options in 
>`KinesisProducerOptionsMapper`. The `getOptions` method of the table returns 
>an `UnmodifiableMap` which is not mutable.

If the sink table is created via SQL, the error does not occur:
{code:java}
tEnv.executeSql("CREATE TABLE sinkTable " + descriptor.toString());
{code}
because `ResolvedCatalogTable.getOptions` returns a regular `HashMap`.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [DISCUSS] Externalized Python Connector Release/Dependency Process

[Ahmed Hamdy]

Hi Danny
+1 (non-binding)
Best Regards
Ahmed Hamdy


On Tue, 9 Jan 2024 at 11:59, Xingbo Huang  wrote:

> Hi Danny,
>
> +1
>
> Thanks a lot for investigating this. Let me share the current code
> management and release situation of pyflink here. I hope it will be helpful
> to you.
>
> Since Flink 1.13, release managers need to release two python packages to
> pypi, apache-flink[1] and apache-flink-libraries[2]. apache-flink contains
> all pyflink python code and apache-flink-libraries contains the jar package
> corresponding to flink binary. The reason why the content of
> apache-flink-libaries is not put into apache-flink is because starting from
> Flink 1.11, pyflink provides different python versions and platform wheel
> packages. If all wheel packages contain these jar packages, the space of
> apache-flink will quickly increase, but pypi's project space is limited(I
> applied to expand apache-flink twice), so in 1.13, I move the corresponding
> jar package from apache-flink to an independent apache-flink-libraries
> package.
>
> Since each apache-connector wheel package today is shared by the platform,
> we do not need to publish a corresponding apache-libraries package for a
> connector currently, but we still need to package the corresponding jar of
> the connector into the corresponding apche-connector pypi package.
>
> [1] https://pypi.org/project/apache-flink/
> [2] https://pypi.org/project/apache-flink-libraries/
>
> Best,
> Xingbo
>
> Leonard Xu  于2024年1月9日周二 13:46写道：
>
> > +1
> >
> > Thanks Danny for driving this.
> >
> > Best,
> > Leonard
> >
> >
> > > 2024年1月9日 上午2:01，Márton Balassi  写道：
> > >
> > > +1
> > >
> > > Thanks, Danny - I really appreciate you taking the time for the
> in-depth
> > > investigation. Please proceed, looking forward to your experience.
> > >
> > > On Mon, Jan 8, 2024 at 6:04 PM Martijn Visser <
> martijnvis...@apache.org>
> > > wrote:
> > >
> > >> Thanks for investigating Danny. It looks like the best direction to go
> > to
> > >> :)
> > >>
> > >> On Mon, Jan 8, 2024 at 5:56 PM Péter Váry <
> peter.vary.apa...@gmail.com>
> > >> wrote:
> > >>>
> > >>> Thanks Danny for working on this!
> > >>>
> > >>> It would be good to do this in a way that the different connectors
> > could
> > >>> reuse as much code as possible, so if possible put most of the code
> to
> > >> the
> > >>> flink connector shared utils repo [1]
> > >>>
> > >>> +1 from for the general direction (non-binding)
> > >>>
> > >>> Thanks,
> > >>> Peter
> > >>>
> > >>> [1] https://github.com/apache/flink-connector-shared-utils
> > >>>
> > >>>
> > >>> Danny Cranmer  ezt írta (időpont: 2024.
> jan.
> > >> 8.,
> > >>> H, 17:31):
> > >>>
> >  Hello all,
> > 
> >  I have been working with Péter and Marton on externalizing python
> >  connectors [1] from the main repo to the connector repositories. We
> > >> have
> >  the code moved and the CI running tests for Kafka and AWS
> Connectors.
> > >> I am
> >  now looking into the release process.
> > 
> >  When we undertake a Flink release we perform the following steps
> [2],
> >  regarding Python: 1/ run python build on CI, 2/ download Wheels
> > >> artifacts,
> >  3/ upload artifacts to the dist and 4/ deploy to pypi. The plan is
> to
> >  follow the same steps for connectors, using Github actions instead
> of
> > >> Azure
> >  pipeline.
> > 
> >  Today we have a single pypi project for pyflink that contains all
> the
> > >> Flink
> >  libs, apache-flink [3]. I propose we create a new pypi project per
> >  connector using the existing connector version, and following naming
> >  convention: apache-, for example:
> >  apache-flink-connector-aws, apache-flink-connector-kafka. Therefore
> to
> > >> use
> >  a DataStream API connector in python, users would need to first
> > >> install the
> >  lib, for example "python -m pip install apache-flink-connector-aws".
> > 
> >  Once we have consensus I will update the release process and
> perform a
> >  release of the flink-connector-aws project to test it end-to-end. I
> > >> look
> >  forward to any feedback.
> > 
> >  Thanks,
> >  Danny
> > 
> >  [1] https://issues.apache.org/jira/browse/FLINK-33528
> >  [2]
> > 
> > >>
> >
> https://cwiki.apache.org/confluence/display/FLINK/Creating+a+Flink+Release
> >  [3] https://pypi.org/project/apache-flink/
> > 
> > >>
> >
> >
>

[jira] [Created] (FLINK-34045) Add docs generation to workflow

[Matthias Pohl (Jira)]

Matthias Pohl created FLINK-34045:
-

 Summary: Add docs generation to workflow
 Key: FLINK-34045
 URL: https://issues.apache.org/jira/browse/FLINK-34045
 Project: Flink
  Issue Type: Sub-task
  Components: Build System / CI
Affects Versions: 1.18.0, 1.19.0
Reporter: Matthias Pohl


The goal of this subtask is to mimick the optional docs generation from the 
Azure Pipelines workflow.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Re: [VOTE] Accept Flink CDC into Apache Flink

[Peter Huang]

+1 (non-binding)


Best Regards
Peter Huang


On Tue, Jan 9, 2024 at 5:26 AM Jane Chan  wrote:

> +1 (non-binding)
>
> Best,
> Jane
>
> On Tue, Jan 9, 2024 at 8:41 PM Lijie Wang 
> wrote:
>
> > +1 (non-binding)
> >
> > Best,
> > Lijie
> >
> > Jiabao Sun  于2024年1月9日周二 19:28写道：
> >
> > > +1 (non-binding)
> > >
> > > Best,
> > > Jiabao
> > >
> > >
> > > On 2024/01/09 09:58:04 xiangyu feng wrote:
> > > > +1 (non-binding)
> > > >
> > > > Regards,
> > > > Xiangyu Feng
> > > >
> > > > Danny Cranmer  于2024年1月9日周二 17:50写道：
> > > >
> > > > > +1 (binding)
> > > > >
> > > > > Thanks,
> > > > > Danny
> > > > >
> > > > > On Tue, Jan 9, 2024 at 9:31 AM Feng Jin  wrote:
> > > > >
> > > > > > +1 (non-binding)
> > > > > >
> > > > > > Best,
> > > > > > Feng Jin
> > > > > >
> > > > > > On Tue, Jan 9, 2024 at 5:29 PM Yuxin Tan 
> wrote:
> > > > > >
> > > > > > > +1 (non-binding)
> > > > > > >
> > > > > > > Best,
> > > > > > > Yuxin
> > > > > > >
> > > > > > >
> > > > > > > Márton Balassi  于2024年1月9日周二 17:25写道：
> > > > > > >
> > > > > > > > +1 (binding)
> > > > > > > >
> > > > > > > > On Tue, Jan 9, 2024 at 10:15 AM Leonard Xu 
> > > > > wrote:
> > > > > > > >
> > > > > > > > > +1(binding)
> > > > > > > > >
> > > > > > > > > Best,
> > > > > > > > > Leonard
> > > > > > > > >
> > > > > > > > > > 2024年1月9日 下午5:08，Yangze Guo  写道：
> > > > > > > > > >
> > > > > > > > > > +1 (non-binding)
> > > > > > > > > >
> > > > > > > > > > Best,
> > > > > > > > > > Yangze Guo
> > > > > > > > > >
> > > > > > > > > > On Tue, Jan 9, 2024 at 5:06 PM Robert Metzger <
> > > > > rmetz...@apache.org
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > >>
> > > > > > > > > >> +1 (binding)
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >> On Tue, Jan 9, 2024 at 9:54 AM Guowei Ma <
> gu...@gmail.com
> > >
> > > > > > > > wrote:
> > > > > > > > > >>
> > > > > > > > > >>> +1 (binding)
> > > > > > > > > >>> Best,
> > > > > > > > > >>> Guowei
> > > > > > > > > >>>
> > > > > > > > > >>>
> > > > > > > > > >>> On Tue, Jan 9, 2024 at 4:49 PM Rui Fan <
> 19...@gmail.com>
> > > > > > > wrote:
> > > > > > > > > >>>
> > > > > > > > >  +1 (non-binding)
> > > > > > > > > 
> > > > > > > > >  Best,
> > > > > > > > >  Rui
> > > > > > > > > 
> > > > > > > > >  On Tue, Jan 9, 2024 at 4:41 PM Hang Ruan <
> > > > > > ruanhang1...@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > > +1 (non-binding)
> > > > > > > > > >
> > > > > > > > > > Best,
> > > > > > > > > > Hang
> > > > > > > > > >
> > > > > > > > > > gongzhongqiang  于2024年1月9日周二
> > > > > > 16:25写道：
> > > > > > > > > >
> > > > > > > > > >> +1 non-binding
> > > > > > > > > >>
> > > > > > > > > >> Best,
> > > > > > > > > >> Zhongqiang
> > > > > > > > > >>
> > > > > > > > > >> Leonard Xu  于2024年1月9日周二 15:05写道：
> > > > > > > > > >>
> > > > > > > > > >>> Hello all,
> > > > > > > > > >>>
> > > > > > > > > >>> This is the official vote whether to accept the
> Flink
> > > CDC
> > > > > > code
> > > > > > > > > >> contribution
> > > > > > > > > >>> to Apache Flink.
> > > > > > > > > >>>
> > > > > > > > > >>> The current Flink CDC code, documentation, and
> > website
> > > can
> > > > > be
> > > > > > > > > >>> found here:
> > > > > > > > > >>> code:
> > > https://github.com/ververica/flink-cdc-connectors <
> > > > > > > > > >>> https://github.com/ververica/flink-cdc-connectors>
> > > > > > > > > >>> docs:
> > > https://ververica.github.io/flink-cdc-connectors/ <
> > > > > > > > > >>> https://ververica.github.io/flink-cdc-connectors/>
> > > > > > > > > >>>
> > > > > > > > > >>> This vote should capture whether the Apache Flink
> > > community
> > > > > > is
> > > > > > > > > > interested
> > > > > > > > > >>> in accepting, maintaining, and evolving Flink CDC.
> > > > > > > > > >>>
> > > > > > > > > >>> Regarding my original proposal[1] in the dev
> mailing
> > > list,
> > > > > I
> > > > > > > > firmly
> > > > > > > > > >> believe
> > > > > > > > > >>> that this initiative aligns perfectly with Flink.
> For
> > > the
> > > > > > Flink
> > > > > > > > > >> community,
> > > > > > > > > >>> it represents an opportunity to bolster Flink's
> > > competitive
> > > > > > > edge
> > > > > > > > in
> > > > > > > > > >>> streaming
> > > > > > > > > >>> data integration, fostering the robust growth and
> > > > > prosperity
> > > > > > of
> > > > > > > > the
> > > > > > > > > >> Apache
> > > > > > > > > >>> Flink
> > > > > > > > > >>> ecosystem. For the Flink CDC project, becoming a
> > > > > sub-project
> > > > > > of
> > > > > > > > >  Apache
> > > > > > > > > >>> Flink
> > > > > > > > > >>> means becoming an integral part of a neutral
> > > open-source
> > > > > > > > community,
> > > > > > > > > >>> capable of
> > > > > > > > > >>> attracting a more diverse pool of contributors.
> > > > > > >

Re: Re: [VOTE] Accept Flink CDC into Apache Flink

[Venkata Sanath Muppalla]

+1 (non-binding)

Thanks,
Sanath

On Tue, Jan 9, 2024 at 11:16 AM Peter Huang 
wrote:

> +1 (non-binding)
>
>
> Best Regards
> Peter Huang
>
>
> On Tue, Jan 9, 2024 at 5:26 AM Jane Chan  wrote:
>
> > +1 (non-binding)
> >
> > Best,
> > Jane
> >
> > On Tue, Jan 9, 2024 at 8:41 PM Lijie Wang 
> > wrote:
> >
> > > +1 (non-binding)
> > >
> > > Best,
> > > Lijie
> > >
> > > Jiabao Sun  于2024年1月9日周二 19:28写道：
> > >
> > > > +1 (non-binding)
> > > >
> > > > Best,
> > > > Jiabao
> > > >
> > > >
> > > > On 2024/01/09 09:58:04 xiangyu feng wrote:
> > > > > +1 (non-binding)
> > > > >
> > > > > Regards,
> > > > > Xiangyu Feng
> > > > >
> > > > > Danny Cranmer  于2024年1月9日周二 17:50写道：
> > > > >
> > > > > > +1 (binding)
> > > > > >
> > > > > > Thanks,
> > > > > > Danny
> > > > > >
> > > > > > On Tue, Jan 9, 2024 at 9:31 AM Feng Jin  wrote:
> > > > > >
> > > > > > > +1 (non-binding)
> > > > > > >
> > > > > > > Best,
> > > > > > > Feng Jin
> > > > > > >
> > > > > > > On Tue, Jan 9, 2024 at 5:29 PM Yuxin Tan 
> > wrote:
> > > > > > >
> > > > > > > > +1 (non-binding)
> > > > > > > >
> > > > > > > > Best,
> > > > > > > > Yuxin
> > > > > > > >
> > > > > > > >
> > > > > > > > Márton Balassi  于2024年1月9日周二 17:25写道：
> > > > > > > >
> > > > > > > > > +1 (binding)
> > > > > > > > >
> > > > > > > > > On Tue, Jan 9, 2024 at 10:15 AM Leonard Xu <
> xb...@gmail.com>
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > +1(binding)
> > > > > > > > > >
> > > > > > > > > > Best,
> > > > > > > > > > Leonard
> > > > > > > > > >
> > > > > > > > > > > 2024年1月9日 下午5:08，Yangze Guo  写道：
> > > > > > > > > > >
> > > > > > > > > > > +1 (non-binding)
> > > > > > > > > > >
> > > > > > > > > > > Best,
> > > > > > > > > > > Yangze Guo
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Jan 9, 2024 at 5:06 PM Robert Metzger <
> > > > > > rmetz...@apache.org
> > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > >>
> > > > > > > > > > >> +1 (binding)
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >> On Tue, Jan 9, 2024 at 9:54 AM Guowei Ma <
> > gu...@gmail.com
> > > >
> > > > > > > > > wrote:
> > > > > > > > > > >>
> > > > > > > > > > >>> +1 (binding)
> > > > > > > > > > >>> Best,
> > > > > > > > > > >>> Guowei
> > > > > > > > > > >>>
> > > > > > > > > > >>>
> > > > > > > > > > >>> On Tue, Jan 9, 2024 at 4:49 PM Rui Fan <
> > 19...@gmail.com>
> > > > > > > > wrote:
> > > > > > > > > > >>>
> > > > > > > > > >  +1 (non-binding)
> > > > > > > > > > 
> > > > > > > > > >  Best,
> > > > > > > > > >  Rui
> > > > > > > > > > 
> > > > > > > > > >  On Tue, Jan 9, 2024 at 4:41 PM Hang Ruan <
> > > > > > > ruanhang1...@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > > 
> > > > > > > > > > > +1 (non-binding)
> > > > > > > > > > >
> > > > > > > > > > > Best,
> > > > > > > > > > > Hang
> > > > > > > > > > >
> > > > > > > > > > > gongzhongqiang  于2024年1月9日周二
> > > > > > > 16:25写道：
> > > > > > > > > > >
> > > > > > > > > > >> +1 non-binding
> > > > > > > > > > >>
> > > > > > > > > > >> Best,
> > > > > > > > > > >> Zhongqiang
> > > > > > > > > > >>
> > > > > > > > > > >> Leonard Xu  于2024年1月9日周二
> 15:05写道：
> > > > > > > > > > >>
> > > > > > > > > > >>> Hello all,
> > > > > > > > > > >>>
> > > > > > > > > > >>> This is the official vote whether to accept the
> > Flink
> > > > CDC
> > > > > > > code
> > > > > > > > > > >> contribution
> > > > > > > > > > >>> to Apache Flink.
> > > > > > > > > > >>>
> > > > > > > > > > >>> The current Flink CDC code, documentation, and
> > > website
> > > > can
> > > > > > be
> > > > > > > > > > >>> found here:
> > > > > > > > > > >>> code:
> > > > https://github.com/ververica/flink-cdc-connectors <
> > > > > > > > > > >>>
> https://github.com/ververica/flink-cdc-connectors>
> > > > > > > > > > >>> docs:
> > > > https://ververica.github.io/flink-cdc-connectors/ <
> > > > > > > > > > >>>
> https://ververica.github.io/flink-cdc-connectors/>
> > > > > > > > > > >>>
> > > > > > > > > > >>> This vote should capture whether the Apache Flink
> > > > community
> > > > > > > is
> > > > > > > > > > > interested
> > > > > > > > > > >>> in accepting, maintaining, and evolving Flink
> CDC.
> > > > > > > > > > >>>
> > > > > > > > > > >>> Regarding my original proposal[1] in the dev
> > mailing
> > > > list,
> > > > > > I
> > > > > > > > > firmly
> > > > > > > > > > >> believe
> > > > > > > > > > >>> that this initiative aligns perfectly with Flink.
> > For
> > > > the
> > > > > > > Flink
> > > > > > > > > > >> community,
> > > > > > > > > > >>> it represents an opportunity to bolster Flink's
> > > > competitive
> > > > > > > > edge
> > > > > > > > > in
> > > > > > > > > > >>> streaming
> > > > > > > > > > >>> data integration, fostering the robust growth and
> > > > > > prosperity
> > > > > > > of
> > > > > > > > > the
> > > > > > > > > > >>

Re: Re: [VOTE] Accept Flink CDC into Apache Flink

[Sharath]

+1 (non-binding)

Best,
Sharath

On Tue, Jan 9, 2024 at 1:02 PM Venkata Sanath Muppalla 
wrote:

> +1 (non-binding)
>
> Thanks,
> Sanath
>
> On Tue, Jan 9, 2024 at 11:16 AM Peter Huang 
> wrote:
>
> > +1 (non-binding)
> >
> >
> > Best Regards
> > Peter Huang
> >
> >
> > On Tue, Jan 9, 2024 at 5:26 AM Jane Chan  wrote:
> >
> > > +1 (non-binding)
> > >
> > > Best,
> > > Jane
> > >
> > > On Tue, Jan 9, 2024 at 8:41 PM Lijie Wang 
> > > wrote:
> > >
> > > > +1 (non-binding)
> > > >
> > > > Best,
> > > > Lijie
> > > >
> > > > Jiabao Sun  于2024年1月9日周二 19:28写道：
> > > >
> > > > > +1 (non-binding)
> > > > >
> > > > > Best,
> > > > > Jiabao
> > > > >
> > > > >
> > > > > On 2024/01/09 09:58:04 xiangyu feng wrote:
> > > > > > +1 (non-binding)
> > > > > >
> > > > > > Regards,
> > > > > > Xiangyu Feng
> > > > > >
> > > > > > Danny Cranmer  于2024年1月9日周二 17:50写道：
> > > > > >
> > > > > > > +1 (binding)
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Danny
> > > > > > >
> > > > > > > On Tue, Jan 9, 2024 at 9:31 AM Feng Jin 
> wrote:
> > > > > > >
> > > > > > > > +1 (non-binding)
> > > > > > > >
> > > > > > > > Best,
> > > > > > > > Feng Jin
> > > > > > > >
> > > > > > > > On Tue, Jan 9, 2024 at 5:29 PM Yuxin Tan 
> > > wrote:
> > > > > > > >
> > > > > > > > > +1 (non-binding)
> > > > > > > > >
> > > > > > > > > Best,
> > > > > > > > > Yuxin
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Márton Balassi  于2024年1月9日周二 17:25写道：
> > > > > > > > >
> > > > > > > > > > +1 (binding)
> > > > > > > > > >
> > > > > > > > > > On Tue, Jan 9, 2024 at 10:15 AM Leonard Xu <
> > xb...@gmail.com>
> > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > +1(binding)
> > > > > > > > > > >
> > > > > > > > > > > Best,
> > > > > > > > > > > Leonard
> > > > > > > > > > >
> > > > > > > > > > > > 2024年1月9日 下午5:08，Yangze Guo  写道：
> > > > > > > > > > > >
> > > > > > > > > > > > +1 (non-binding)
> > > > > > > > > > > >
> > > > > > > > > > > > Best,
> > > > > > > > > > > > Yangze Guo
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Jan 9, 2024 at 5:06 PM Robert Metzger <
> > > > > > > rmetz...@apache.org
> > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > > >>
> > > > > > > > > > > >> +1 (binding)
> > > > > > > > > > > >>
> > > > > > > > > > > >>
> > > > > > > > > > > >> On Tue, Jan 9, 2024 at 9:54 AM Guowei Ma <
> > > gu...@gmail.com
> > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > > >>
> > > > > > > > > > > >>> +1 (binding)
> > > > > > > > > > > >>> Best,
> > > > > > > > > > > >>> Guowei
> > > > > > > > > > > >>>
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> On Tue, Jan 9, 2024 at 4:49 PM Rui Fan <
> > > 19...@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > > > > >>>
> > > > > > > > > > >  +1 (non-binding)
> > > > > > > > > > > 
> > > > > > > > > > >  Best,
> > > > > > > > > > >  Rui
> > > > > > > > > > > 
> > > > > > > > > > >  On Tue, Jan 9, 2024 at 4:41 PM Hang Ruan <
> > > > > > > > ruanhang1...@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > > 
> > > > > > > > > > > > +1 (non-binding)
> > > > > > > > > > > >
> > > > > > > > > > > > Best,
> > > > > > > > > > > > Hang
> > > > > > > > > > > >
> > > > > > > > > > > > gongzhongqiang  于2024年1月9日周二
> > > > > > > > 16:25写道：
> > > > > > > > > > > >
> > > > > > > > > > > >> +1 non-binding
> > > > > > > > > > > >>
> > > > > > > > > > > >> Best,
> > > > > > > > > > > >> Zhongqiang
> > > > > > > > > > > >>
> > > > > > > > > > > >> Leonard Xu  于2024年1月9日周二
> > 15:05写道：
> > > > > > > > > > > >>
> > > > > > > > > > > >>> Hello all,
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> This is the official vote whether to accept the
> > > Flink
> > > > > CDC
> > > > > > > > code
> > > > > > > > > > > >> contribution
> > > > > > > > > > > >>> to Apache Flink.
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> The current Flink CDC code, documentation, and
> > > > website
> > > > > can
> > > > > > > be
> > > > > > > > > > > >>> found here:
> > > > > > > > > > > >>> code:
> > > > > https://github.com/ververica/flink-cdc-connectors <
> > > > > > > > > > > >>>
> > https://github.com/ververica/flink-cdc-connectors>
> > > > > > > > > > > >>> docs:
> > > > > https://ververica.github.io/flink-cdc-connectors/ <
> > > > > > > > > > > >>>
> > https://ververica.github.io/flink-cdc-connectors/>
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> This vote should capture whether the Apache
> Flink
> > > > > community
> > > > > > > > is
> > > > > > > > > > > > interested
> > > > > > > > > > > >>> in accepting, maintaining, and evolving Flink
> > CDC.
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> Regarding my original proposal[1] in the dev
> > > mailing
> > > > > list,
> > > > > > > I
> > > > > > > > > > firmly
> > > > > > > > > > > >> believe
> > > > > > > > > > > >>> that this initiative aligns pe

Re: [DISCUSS] FLIP 411: Chaining-agnostic Operator ID generation for improved state compatibility on parallelism change

[David Morávek]

Hi Zhanghao,

Thanks for the FLIP. What you're proposing makes a lot of sense +1

Have you thought about how this works with unaligned checkpoints in case
you go from unchained to chained? I think it should be fine because this
scenario should only apply to forward/rebalance scenarios where we, as far
as I recall, force alignment anyway, so there should be no exchanges to
snapshot. It might just work, but something to double-check. Maybe @Piotr
Nowojski  could confirm it.

Best,
D.

On Wed, Jan 3, 2024 at 7:10 AM Zhanghao Chen 
wrote:

> Dear Flink devs,
>
> I'd like to start a discussion on FLIP 411: Chaining-agnostic Operator ID
> generation for improved state compatibility on parallelism change [1].
>
> Currently, when user does not explicitly set operator UIDs, the chaining
> behavior will still affect state compatibility, as the generation of the
> Operator ID is dependent on its chained output nodes. For example, a simple
> source->sink DAG with source and sink chained together is state
> incompatible with an otherwise identical DAG with source and sink unchained
> (either because the parallelisms of the two ops are changed to be unequal
> or chaining is disabled). This greatly limits the flexibility to perform
> chain-breaking/building for performance tuning.
>
> The dependency on chained output nodes for Operator ID generation can be
> traced back to Flink 1.2. It is unclear at this point on why chained output
> nodes are involved in the algorithm, but the following history background
> might be related: prior to Flink 1.3, Flink runtime takes the snapshots by
> the operator ID of the first vertex in a chain, so it somewhat makes sense
> to include chained output nodes into the algorithm as
> chain-breaking/building is expected to break state-compatibility anyway.
>
> Given that operator-level state recovery within a chain has long been
> supported since Flink 1.3, I propose to introduce StreamGraphHasherV3 that
> is agnostic of the chaining behavior of operators, so that users are free
> to tune the parallelism of individual operators without worrying about
> state incompatibility. We can make the V3 hasher an optional choice in
> Flink 1.19, and make it the default hasher in 2.0 for backwards
> compatibility.
>
> Looking forward to your suggestions on it, thanks~
>
> [1]
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-411%3A+Chaining-agnostic+Operator+ID+generation+for+improved+state+compatibility+on+parallelism+change
>
> Best,
> Zhanghao Chen
>

Re: FW: [ANNOUNCE] New Apache Flink Committer - Alexander Fedulov

[David Morávek]

Congrats, Alex!

Best,
D.

On Fri, Jan 5, 2024 at 7:25 AM Sergey Nuyanzin  wrote:

> Congratulations, Alex!
>
> On Fri, Jan 5, 2024, 05:12 Lincoln Lee  wrote:
>
> > Congratulations, Alex!
> >
> > Best,
> > Lincoln Lee
> >
> >
> > Alexander Fedulov  于2024年1月4日周四 19:08写道：
> >
> > > Thanks, everyone! It is great to be part of such an active and
> > > collaborative community!
> > >
> > > Best,
> > > Alex
> > >
> > > On Thu, 4 Jan 2024 at 10:10, Etienne Chauchot 
> > > wrote:
> > >
> > > > Congrats! Welcome onboard.
> > > >
> > > > Best
> > > >
> > > > Etienne
> > > >
> > > > Le 04/01/2024 à 03:14, Jane Chan a écrit :
> > > > > Congratulations, Alex!
> > > > >
> > > > > Best,
> > > > > Jane
> > > > >
> > > > > On Thu, Jan 4, 2024 at 10:03 AM Junrui Lee
> > > wrote:
> > > > >
> > > > >> Congratulations, Alex!
> > > > >>
> > > > >> Best,
> > > > >> Junrui
> > > > >>
> > > > >> weijie guo  于2024年1月4日周四 09:57写道：
> > > > >>
> > > > >>> Congratulations, Alex!
> > > > >>>
> > > > >>> Best regards,
> > > > >>>
> > > > >>> Weijie
> > > > >>>
> > > > >>>
> > > > >>> Steven Wu  于2024年1月4日周四 02:07写道：
> > > > >>>
> > > >  Congra, Alex! Well deserved!
> > > > 
> > > >  On Wed, Jan 3, 2024 at 2:31 AM David Radley<
> > david_rad...@uk.ibm.com
> > > >
> > > >  wrote:
> > > > 
> > > > > Sorry for my typo.
> > > > >
> > > > > Many congratulations Alex!
> > > > >
> > > > > From: David Radley
> > > > > Date: Wednesday, 3 January 2024 at 10:23
> > > > > To: David Anderson
> > > > > Cc:dev@flink.apache.org  
> > > > > Subject: Re: [EXTERNAL] [ANNOUNCE] New Apache Flink Committer -
> > > > >>> Alexander
> > > > > Fedulov
> > > > > Many Congratulations David .
> > > > >
> > > > > From: Maximilian Michels
> > > > > Date: Tuesday, 2 January 2024 at 12:16
> > > > > To: dev
> > > > > Cc: Alexander Fedulov
> > > > > Subject: [EXTERNAL] [ANNOUNCE] New Apache Flink Committer -
> > > Alexander
> > > > > Fedulov
> > > > > Happy New Year everyone,
> > > > >
> > > > > I'd like to start the year off by announcing Alexander Fedulov
> > as a
> > > > > new Flink committer.
> > > > >
> > > > > Alex has been active in the Flink community since 2019. He has
> > > > > contributed more than 100 commits to Flink, its Kubernetes
> > > operator,
> > > > > and various connectors [1][2].
> > > > >
> > > > > Especially noteworthy are his contributions on deprecating and
> > > > > migrating the old Source API functions and test harnesses, the
> > > > > enhancement to flame graphs, the dynamic rescale time
> computation
> > > in
> > > > > Flink Autoscaling, as well as all the small enhancements Alex
> has
> > > > > contributed which make a huge difference.
> > > > >
> > > > > Beyond code contributions, Alex has been an active community
> > member
> > > > > with his activity on the mailing lists [3][4], as well as
> various
> > > > > talks and blog posts about Apache Flink [5][6].
> > > > >
> > > > > Congratulations Alex! The Flink community is proud to have you.
> > > > >
> > > > > Best,
> > > > > The Flink PMC
> > > > >
> > > > > [1]
> > > > >
> > > > >>>
> > > >
> > https://github.com/search?type=commits&q=author%3Aafedulov+org%3Aapache
> > > > > [2]
> > > > >
> > > > >>
> > > >
> > >
> >
> https://issues.apache.org/jira/browse/FLINK-28229?jql=status%20in%20(Resolved%2C%20Closed)%20AND%20assignee%20in%20(afedulov)%20ORDER%20BY%20resolved%20DESC%2C%20created%20DESC
> > > > > [3]
> > > > >>>
> > https://lists.apache.org/list?dev@flink.apache.org:lte=100M:Fedulov
> > > > > [4]
> > > > >>>
> > https://lists.apache.org/list?u...@flink.apache.org:lte=100M:Fedulov
> > > > > [5]
> > > > >
> > > > >>
> > > >
> > >
> >
> https://flink.apache.org/2020/01/15/advanced-flink-application-patterns-vol.1-case-study-of-a-fraud-detection-system/
> > > > > [6]
> > > > >
> > > > >>
> > > >
> > >
> >
> https://www.ververica.com/blog/presenting-our-streaming-concepts-introduction-to-flink-video-series
> > > > > Unless otherwise stated above:
> > > > >
> > > > > IBM United Kingdom Limited
> > > > > Registered in England and Wales with number 741598
> > > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hants.
> > PO6
> > > > >> 3AU
> > >
> >
>

[jira] [Created] (FLINK-34046) Add metrics to AsyncWaitOperator Retry Flow

[Dinesh (Jira)]

Dinesh created FLINK-34046:
--

 Summary: Add metrics to AsyncWaitOperator Retry Flow
 Key: FLINK-34046
 URL: https://issues.apache.org/jira/browse/FLINK-34046
 Project: Flink
  Issue Type: Improvement
  Components: API / DataStream
Reporter: Dinesh


AsyncWaitOperator supports retry if retry Strategy is set. But there is no 
metrics to count the messages retried, message retry succeeded and dropped 
message count after reaching configured retry count.

To address this we propose to add metrics for Retry Count, Retry Success Count 
and Dropped after max retry Count.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [DISCUSS] FLIP-329: Add operator attribute to specify support for object-reuse

[Xuannan Su]

Hi Lu,

You can find information about the FLIP process on our wiki[1]. Please
let me know if you have any questions.

Best regards,
Xuannan

[1] 
https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals

On Tue, Jan 9, 2024 at 5:36 AM Lu Niu  wrote:
>
> sounds good. Is the requirement to send an email thread about the voting? 
> What else is needed? What's the passing criteria?
>
> Best
> Lu
>
> On Sun, Jan 7, 2024 at 5:41 PM Xuannan Su  wrote:
>>
>> Hi Liu,
>>
>> The voting thread has been open for a long time. We may want to start
>> a new voting thread. WDYT?
>>
>> Best,
>> Xuannan
>>
>> On Sat, Jan 6, 2024 at 1:51 AM Lu Niu  wrote:
>> >
>> > Thank you Dong and Xuannan!
>> >
>> > Yes. We can take on this task. Any help during bootstrapping would be 
>> > greatly appreciated! I realize there is already a voting thread "[VOTE] 
>> > FLIP-329: Add operator attribute to specify support for object-reuse". 
>> > What else do we need?
>> >
>> > Best
>> > Lu
>> >
>> > On Fri, Jan 5, 2024 at 12:46 AM Xuannan Su  wrote:
>> >>
>> >> Hi Lu,
>> >>
>> >> I believe this feature is very useful. However, I currently lack the
>> >> capacity to work on it in the near future. I think it would be great
>> >> if you could take on the task. I am willing to offer assistance if
>> >> there are any questions about the FLIP, or to review the PR if needed.
>> >>
>> >> Please let me know if you are interested in taking over this task. And
>> >> also think that we should start the voting thread if no future
>> >> comments on this FLIP.
>> >>
>> >> Best,
>> >> Xuannan
>> >>
>> >>
>> >>
>> >> On Fri, Jan 5, 2024 at 2:23 PM Dong Lin  wrote:
>> >> >
>> >> > Hi Lu,
>> >> >
>> >> > I am not actively working on Flink and this JIRA recently. If Xuannan 
>> >> > does not plan to work on this anytime soon, I personally think it will 
>> >> > be great if you can help work on this FLIP. Maybe we can start the 
>> >> > voting thread if there is no further comment on this FLIP.
>> >> >
>> >> > Xuannan, what do you think?
>> >> >
>> >> > Thanks,
>> >> > Dong
>> >> >
>> >> >
>> >> > On Fri, Jan 5, 2024 at 2:03 AM Lu Niu  wrote:
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> Is this still under active development? I notice 
>> >> >> https://issues.apache.org/jira/browse/FLINK-32476 is labeled as 
>> >> >> deprioritized. If this is the case, would it be acceptable for us to 
>> >> >> take on the task?
>> >> >>
>> >> >> Best
>> >> >> Lu
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Thu, Oct 19, 2023 at 4:26 PM Ken Krugler 
>> >> >>  wrote:
>> >> >>>
>> >> >>> Hi Dong,
>> >> >>>
>> >> >>> Sorry for not seeing this initially. I did have one question about 
>> >> >>> the description of the issue in the FLIP:
>> >> >>>
>> >> >>> > However, in cases where the upstream and downstream operators do 
>> >> >>> > not store or access references to the input or output records, this 
>> >> >>> > deep-copy overhead becomes unnecessary
>> >> >>>
>> >> >>> I was interested in getting clarification as to what you meant by “or 
>> >> >>> access references…”, to see if it covered this situation:
>> >> >>>
>> >> >>> StreamX —forward--> operator1
>> >> >>> StreamX —forward--> operator2
>> >> >>>
>> >> >>> If operator1 modifies the record, and object re-use is enabled, then 
>> >> >>> operator2 will see the modified version, right?
>> >> >>>
>> >> >>> Thanks,
>> >> >>>
>> >> >>> — Ken
>> >> >>>
>> >> >>> > On Jul 2, 2023, at 7:24 PM, Xuannan Su  
>> >> >>> > wrote:
>> >> >>> >
>> >> >>> > Hi all,
>> >> >>> >
>> >> >>> > Dong(cc'ed) and I are opening this thread to discuss our proposal to
>> >> >>> > add operator attribute to allow operator to specify support for
>> >> >>> > object-reuse [1].
>> >> >>> >
>> >> >>> > Currently, the default configuration for pipeline.object-reuse is 
>> >> >>> > set
>> >> >>> > to false to avoid data corruption, which can result in suboptimal
>> >> >>> > performance. We propose adding APIs that operators can utilize to
>> >> >>> > inform the Flink runtime whether it is safe to reuse the emitted
>> >> >>> > records. This enhancement would enable Flink to maximize its
>> >> >>> > performance using the default configuration.
>> >> >>> >
>> >> >>> > Please refer to the FLIP document for more details about the 
>> >> >>> > proposed
>> >> >>> > design and implementation. We welcome any feedback and opinions on
>> >> >>> > this proposal.
>> >> >>> >
>> >> >>> > Best regards,
>> >> >>> >
>> >> >>> > Dong and Xuannan
>> >> >>> >
>> >> >>> > [1] 
>> >> >>> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=255073749
>> >> >>>
>> >> >>> --
>> >> >>> Ken Krugler
>> >> >>> http://www.scaleunlimited.com
>> >> >>> Custom big data solutions
>> >> >>> Flink & Pinot
>> >> >>>
>> >> >>>
>> >> >>>

Re: [DISCUSS] FLIP 411: Chaining-agnostic Operator ID generation for improved state compatibility on parallelism change

[Zhanghao Chen]

Hi David,

Thanks for the comments. AFAIK, unaligned checkpoints are disabled for 
pointwise connections according to [1], let's wait Piotr for confirmation. The 
issue itself is not directly related to this proposal as well. If a user 
manually specifies UIDs for each of the chained operators and has unaligned 
checkpoints enabled, we will encounter the same issue if they decide to break 
the chain on a later restart and try to recover from a retained cp.

[1] 
https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/ops/state/checkpointing_under_backpressure/


Best,
Zhanghao Chen

From: David Morávek 
Sent: Wednesday, January 10, 2024 6:26
To: dev@flink.apache.org ; Piotr Nowojski 

Subject: Re: [DISCUSS] FLIP 411: Chaining-agnostic Operator ID generation for 
improved state compatibility on parallelism change

Hi Zhanghao,

Thanks for the FLIP. What you're proposing makes a lot of sense +1

Have you thought about how this works with unaligned checkpoints in case
you go from unchained to chained? I think it should be fine because this
scenario should only apply to forward/rebalance scenarios where we, as far
as I recall, force alignment anyway, so there should be no exchanges to
snapshot. It might just work, but something to double-check. Maybe @Piotr
Nowojski  could confirm it.

Best,
D.

On Wed, Jan 3, 2024 at 7:10 AM Zhanghao Chen 
wrote:

> Dear Flink devs,
>
> I'd like to start a discussion on FLIP 411: Chaining-agnostic Operator ID
> generation for improved state compatibility on parallelism change [1].
>
> Currently, when user does not explicitly set operator UIDs, the chaining
> behavior will still affect state compatibility, as the generation of the
> Operator ID is dependent on its chained output nodes. For example, a simple
> source->sink DAG with source and sink chained together is state
> incompatible with an otherwise identical DAG with source and sink unchained
> (either because the parallelisms of the two ops are changed to be unequal
> or chaining is disabled). This greatly limits the flexibility to perform
> chain-breaking/building for performance tuning.
>
> The dependency on chained output nodes for Operator ID generation can be
> traced back to Flink 1.2. It is unclear at this point on why chained output
> nodes are involved in the algorithm, but the following history background
> might be related: prior to Flink 1.3, Flink runtime takes the snapshots by
> the operator ID of the first vertex in a chain, so it somewhat makes sense
> to include chained output nodes into the algorithm as
> chain-breaking/building is expected to break state-compatibility anyway.
>
> Given that operator-level state recovery within a chain has long been
> supported since Flink 1.3, I propose to introduce StreamGraphHasherV3 that
> is agnostic of the chaining behavior of operators, so that users are free
> to tune the parallelism of individual operators without worrying about
> state incompatibility. We can make the V3 hasher an optional choice in
> Flink 1.19, and make it the default hasher in 2.0 for backwards
> compatibility.
>
> Looking forward to your suggestions on it, thanks~
>
> [1]
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-411%3A+Chaining-agnostic+Operator+ID+generation+for+improved+state+compatibility+on+parallelism+change
>
> Best,
> Zhanghao Chen
>

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

[Qingsheng Ren]

+1 (binding)

- Built from source
- Verified checksum and signature
- Verified that no binary exist in source
- Started a standalone cluster and submit Kafka consuming and producing job
with SQL client
- Reviewed web PR

Thanks for driving this, Jing!

Best,
Qingsheng

On Mon, Jan 8, 2024 at 8:02 PM Jark Wu  wrote:

> Thanks Jing for driving this.
>
> +1 (binding)
>
> - Build and compile the source code locally: *OK*
> - Verified signatures and hashes: *OK*
> - Checked no missing artifacts in the staging area: *OK*
> - Reviewed the website release PR: *OK*
> - Went through the quick start: *OK*
>   * Started a cluster and ran the examples
>   * Verified web ui and log output, nothing unexpected
>
> Best,
> Jark
>
> On Thu, 28 Dec 2023 at 20:59, Yun Tang  wrote:
>
> > Thanks Jing for driving this release.
> >
> > +1 (non-binding)
> >
> >
> >   *
> > Download artifacts and verify the signatures.
> >   *
> > Verified the web PR
> >   *
> > Verified the number of Python packages is 11
> >   *
> > Started a local cluster and verified FLIP-291 to see the rescale results.
> >   *
> > Verified the jar packages were built with JDK8
> >
> > Best
> > Yun Tang
> >
> >
> > 
> > From: Rui Fan <1996fan...@gmail.com>
> > Sent: Thursday, December 28, 2023 10:54
> > To: dev@flink.apache.org 
> > Subject: Re: [VOTE] Release 1.18.1, release candidate #2
> >
> > Thanks Jing for driving this release!
> >
> > +1(non-binding)
> >
> > - Downloaded artifacts
> > - Verified signatures and sha512
> > - The source archives do not contain any binaries
> > - Verified web PR
> > - Build the source with Maven 3 and java8 (Checked the license as well)
> > - bin/start-cluster.sh with java8, it works fine and no any unexpected
> LOG-
> > Ran demo, it's fine:  bin/flink
> > runexamples/streaming/StateMachineExample.jar
> >
> > Best,
> > Rui
> >
> > On Wed, Dec 27, 2023 at 8:45 PM Martijn Visser  >
> > wrote:
> >
> > > Hi Jing,
> > >
> > > Thanks for driving this.
> > >
> > > +1 (binding)
> > >
> > > - Validated hashes
> > > - Verified signature
> > > - Verified that no binaries exist in the source archive
> > > - Build the source with Maven via mvn clean install
> > > -Pcheck-convergence -Dflink.version=1.18.1
> > > - Verified licenses
> > > - Verified web PR
> > > - Started a cluster and the Flink SQL client, successfully read and
> > > wrote with the Kafka connector to Confluent Cloud with AVRO and Schema
> > > Registry enabled
> > > - Started a cluster and submitted a job that checkpoints to GCS without
> > > problems
> > >
> > > Best regards,
> > >
> > > Martijn
> > >
> > > On Thu, Dec 21, 2023 at 4:55 AM gongzhongqiang
> > >  wrote:
> > > >
> > > > Thanks Jing Ge for driving this release.
> > > >
> > > > +1 (non-binding), I have checked:
> > > > [✓] The checksums and signatures are validated
> > > > [✓] The tag checked is fine
> > > > [✓] Built from source is passed
> > > > [✓] The flink-web PR is reviewed and checked
> > > >
> > > >
> > > > Best，
> > > > Zhongqiang Gong
> > >
> >
>

Re:Re: [VOTE] FLIP-387: Support named parameters for functions and call procedures

[Xuyang]

+1(non-binding)--

Best！
Xuyang





在 2024-01-08 00:34:55，"Feng Jin"  写道：
>Hi Alexey
>
>Thank you for the reminder, the link has been updated.
>
>Best,
>Feng Jin
>
>On Sat, Jan 6, 2024 at 12:55 AM Alexey Leonov-Vendrovskiy <
>vendrov...@gmail.com> wrote:
>
>> Thanks for starting the vote!
>> Do you mind adding a link from the FLIP to this thread?
>>
>> Thanks,
>> Alexey
>>
>> On Thu, Jan 4, 2024 at 6:48 PM Feng Jin  wrote:
>>
>> > Hi everyone
>> >
>> > Thanks for all the feedback about the FLIP-387: Support named parameters
>> > for functions and call procedures [1] [2] .
>> >
>> > I'd like to start a vote for it. The vote will be open for at least 72
>> > hours(excluding weekends,until Jan 10, 12:00AM GMT) unless there is an
>> > objection or an insufficient number of votes.
>> >
>> >
>> >
>> > [1]
>> >
>> >
>> https://cwiki.apache.org/confluence/display/FLINK/FLIP-387%3A+Support+named+parameters+for+functions+and+call+procedures
>> > [2] https://lists.apache.org/thread/bto7mpjvcx7d7k86owb00dwrm65jx8cn
>> >
>> >
>> > Best,
>> > Feng Jin
>> >
>>

Re: Re: [VOTE] Accept Flink CDC into Apache Flink

[Dian Fu]

+1 (binding)

Regards,
Dian

On Wed, Jan 10, 2024 at 5:09 AM Sharath  wrote:
>
> +1 (non-binding)
>
> Best,
> Sharath
>
> On Tue, Jan 9, 2024 at 1:02 PM Venkata Sanath Muppalla 
> wrote:
>
> > +1 (non-binding)
> >
> > Thanks,
> > Sanath
> >
> > On Tue, Jan 9, 2024 at 11:16 AM Peter Huang 
> > wrote:
> >
> > > +1 (non-binding)
> > >
> > >
> > > Best Regards
> > > Peter Huang
> > >
> > >
> > > On Tue, Jan 9, 2024 at 5:26 AM Jane Chan  wrote:
> > >
> > > > +1 (non-binding)
> > > >
> > > > Best,
> > > > Jane
> > > >
> > > > On Tue, Jan 9, 2024 at 8:41 PM Lijie Wang 
> > > > wrote:
> > > >
> > > > > +1 (non-binding)
> > > > >
> > > > > Best,
> > > > > Lijie
> > > > >
> > > > > Jiabao Sun  于2024年1月9日周二 19:28写道：
> > > > >
> > > > > > +1 (non-binding)
> > > > > >
> > > > > > Best,
> > > > > > Jiabao
> > > > > >
> > > > > >
> > > > > > On 2024/01/09 09:58:04 xiangyu feng wrote:
> > > > > > > +1 (non-binding)
> > > > > > >
> > > > > > > Regards,
> > > > > > > Xiangyu Feng
> > > > > > >
> > > > > > > Danny Cranmer  于2024年1月9日周二 17:50写道：
> > > > > > >
> > > > > > > > +1 (binding)
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Danny
> > > > > > > >
> > > > > > > > On Tue, Jan 9, 2024 at 9:31 AM Feng Jin 
> > wrote:
> > > > > > > >
> > > > > > > > > +1 (non-binding)
> > > > > > > > >
> > > > > > > > > Best,
> > > > > > > > > Feng Jin
> > > > > > > > >
> > > > > > > > > On Tue, Jan 9, 2024 at 5:29 PM Yuxin Tan 
> > > > wrote:
> > > > > > > > >
> > > > > > > > > > +1 (non-binding)
> > > > > > > > > >
> > > > > > > > > > Best,
> > > > > > > > > > Yuxin
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Márton Balassi  于2024年1月9日周二 17:25写道：
> > > > > > > > > >
> > > > > > > > > > > +1 (binding)
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Jan 9, 2024 at 10:15 AM Leonard Xu <
> > > xb...@gmail.com>
> > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > +1(binding)
> > > > > > > > > > > >
> > > > > > > > > > > > Best,
> > > > > > > > > > > > Leonard
> > > > > > > > > > > >
> > > > > > > > > > > > > 2024年1月9日 下午5:08，Yangze Guo  写道：
> > > > > > > > > > > > >
> > > > > > > > > > > > > +1 (non-binding)
> > > > > > > > > > > > >
> > > > > > > > > > > > > Best,
> > > > > > > > > > > > > Yangze Guo
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, Jan 9, 2024 at 5:06 PM Robert Metzger <
> > > > > > > > rmetz...@apache.org
> > > > > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> +1 (binding)
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> On Tue, Jan 9, 2024 at 9:54 AM Guowei Ma <
> > > > gu...@gmail.com
> > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>> +1 (binding)
> > > > > > > > > > > > >>> Best,
> > > > > > > > > > > > >>> Guowei
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> On Tue, Jan 9, 2024 at 4:49 PM Rui Fan <
> > > > 19...@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > > > > >>>
> > > > > > > > > > > >  +1 (non-binding)
> > > > > > > > > > > > 
> > > > > > > > > > > >  Best,
> > > > > > > > > > > >  Rui
> > > > > > > > > > > > 
> > > > > > > > > > > >  On Tue, Jan 9, 2024 at 4:41 PM Hang Ruan <
> > > > > > > > > ruanhang1...@gmail.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > > +1 (non-binding)
> > > > > > > > > > > > >
> > > > > > > > > > > > > Best,
> > > > > > > > > > > > > Hang
> > > > > > > > > > > > >
> > > > > > > > > > > > > gongzhongqiang  于2024年1月9日周二
> > > > > > > > > 16:25写道：
> > > > > > > > > > > > >
> > > > > > > > > > > > >> +1 non-binding
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Best,
> > > > > > > > > > > > >> Zhongqiang
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Leonard Xu  于2024年1月9日周二
> > > 15:05写道：
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>> Hello all,
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> This is the official vote whether to accept the
> > > > Flink
> > > > > > CDC
> > > > > > > > > code
> > > > > > > > > > > > >> contribution
> > > > > > > > > > > > >>> to Apache Flink.
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> The current Flink CDC code, documentation, and
> > > > > website
> > > > > > can
> > > > > > > > be
> > > > > > > > > > > > >>> found here:
> > > > > > > > > > > > >>> code:
> > > > > > https://github.com/ververica/flink-cdc-connectors <
> > > > > > > > > > > > >>>
> > > https://github.com/ververica/flink-cdc-connectors>
> > > > > > > > > > > > >>> docs:
> > > > > > https://ververica.github.io/flink-cdc-connectors/ <
> > > > > > > > > > > > >>>
> > > https://ververica.github.io/flink-cdc-connectors/>
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> This vote should capture whether the Apache
> > Flink
> > > > > > community
> > 

Re: Re: [VOTE] Accept Flink CDC into Apache Flink

[Xingbo Huang]

+1 (binding)

Best,
Xingbo

Dian Fu  于2024年1月10日周三 11:35写道：

> +1 (binding)
>
> Regards,
> Dian
>
> On Wed, Jan 10, 2024 at 5:09 AM Sharath  wrote:
> >
> > +1 (non-binding)
> >
> > Best,
> > Sharath
> >
> > On Tue, Jan 9, 2024 at 1:02 PM Venkata Sanath Muppalla <
> sanath...@gmail.com>
> > wrote:
> >
> > > +1 (non-binding)
> > >
> > > Thanks,
> > > Sanath
> > >
> > > On Tue, Jan 9, 2024 at 11:16 AM Peter Huang <
> huangzhenqiu0...@gmail.com>
> > > wrote:
> > >
> > > > +1 (non-binding)
> > > >
> > > >
> > > > Best Regards
> > > > Peter Huang
> > > >
> > > >
> > > > On Tue, Jan 9, 2024 at 5:26 AM Jane Chan 
> wrote:
> > > >
> > > > > +1 (non-binding)
> > > > >
> > > > > Best,
> > > > > Jane
> > > > >
> > > > > On Tue, Jan 9, 2024 at 8:41 PM Lijie Wang <
> wangdachui9...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > +1 (non-binding)
> > > > > >
> > > > > > Best,
> > > > > > Lijie
> > > > > >
> > > > > > Jiabao Sun  于2024年1月9日周二
> 19:28写道：
> > > > > >
> > > > > > > +1 (non-binding)
> > > > > > >
> > > > > > > Best,
> > > > > > > Jiabao
> > > > > > >
> > > > > > >
> > > > > > > On 2024/01/09 09:58:04 xiangyu feng wrote:
> > > > > > > > +1 (non-binding)
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Xiangyu Feng
> > > > > > > >
> > > > > > > > Danny Cranmer  于2024年1月9日周二 17:50写道：
> > > > > > > >
> > > > > > > > > +1 (binding)
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Danny
> > > > > > > > >
> > > > > > > > > On Tue, Jan 9, 2024 at 9:31 AM Feng Jin 
> > > wrote:
> > > > > > > > >
> > > > > > > > > > +1 (non-binding)
> > > > > > > > > >
> > > > > > > > > > Best,
> > > > > > > > > > Feng Jin
> > > > > > > > > >
> > > > > > > > > > On Tue, Jan 9, 2024 at 5:29 PM Yuxin Tan <
> ta...@gmail.com>
> > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > +1 (non-binding)
> > > > > > > > > > >
> > > > > > > > > > > Best,
> > > > > > > > > > > Yuxin
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Márton Balassi  于2024年1月9日周二 17:25写道：
> > > > > > > > > > >
> > > > > > > > > > > > +1 (binding)
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Jan 9, 2024 at 10:15 AM Leonard Xu <
> > > > xb...@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > +1(binding)
> > > > > > > > > > > > >
> > > > > > > > > > > > > Best,
> > > > > > > > > > > > > Leonard
> > > > > > > > > > > > >
> > > > > > > > > > > > > > 2024年1月9日 下午5:08，Yangze Guo 
> 写道：
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > +1 (non-binding)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Best,
> > > > > > > > > > > > > > Yangze Guo
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Tue, Jan 9, 2024 at 5:06 PM Robert Metzger <
> > > > > > > > > rmetz...@apache.org
> > > > > > > > > > >
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> +1 (binding)
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> On Tue, Jan 9, 2024 at 9:54 AM Guowei Ma <
> > > > > gu...@gmail.com
> > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >>> +1 (binding)
> > > > > > > > > > > > > >>> Best,
> > > > > > > > > > > > > >>> Guowei
> > > > > > > > > > > > > >>>
> > > > > > > > > > > > > >>>
> > > > > > > > > > > > > >>> On Tue, Jan 9, 2024 at 4:49 PM Rui Fan <
> > > > > 19...@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > > > > >>>
> > > > > > > > > > > > >  +1 (non-binding)
> > > > > > > > > > > > > 
> > > > > > > > > > > > >  Best,
> > > > > > > > > > > > >  Rui
> > > > > > > > > > > > > 
> > > > > > > > > > > > >  On Tue, Jan 9, 2024 at 4:41 PM Hang Ruan <
> > > > > > > > > > ruanhang1...@gmail.com>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > +1 (non-binding)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Best,
> > > > > > > > > > > > > > Hang
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > gongzhongqiang 
> 于2024年1月9日周二
> > > > > > > > > > 16:25写道：
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >> +1 non-binding
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> Best,
> > > > > > > > > > > > > >> Zhongqiang
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> Leonard Xu  于2024年1月9日周二
> > > > 15:05写道：
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >>> Hello all,
> > > > > > > > > > > > > >>>
> > > > > > > > > > > > > >>> This is the official vote whether to
> accept the
> > > > > Flink
> > > > > > > CDC
> > > > > > > > > > code
> > > > > > > > > > > > > >> contribution
> > > > > > > > > > > > > >>> to Apache Flink.
> > > > > > > > > > > > > >>>
> > > > > > > > > > > > > >>> The current Flink CDC code, documentation,
> and
> > > > > > website
> > > > > > > can
> > > > > > > > > be
> > > > > > > > > > > > > >>> found here:
> > > > > > > > > > > >

Re: Re: [VOTE] FLIP-387: Support named parameters for functions and call procedures

[Jingsong Li]

+1

On Wed, Jan 10, 2024 at 11:24 AM Xuyang  wrote:
>
> +1(non-binding)--
>
> Best！
> Xuyang
>
>
>
>
>
> 在 2024-01-08 00:34:55，"Feng Jin"  写道：
> >Hi Alexey
> >
> >Thank you for the reminder, the link has been updated.
> >
> >Best,
> >Feng Jin
> >
> >On Sat, Jan 6, 2024 at 12:55 AM Alexey Leonov-Vendrovskiy <
> >vendrov...@gmail.com> wrote:
> >
> >> Thanks for starting the vote!
> >> Do you mind adding a link from the FLIP to this thread?
> >>
> >> Thanks,
> >> Alexey
> >>
> >> On Thu, Jan 4, 2024 at 6:48 PM Feng Jin  wrote:
> >>
> >> > Hi everyone
> >> >
> >> > Thanks for all the feedback about the FLIP-387: Support named parameters
> >> > for functions and call procedures [1] [2] .
> >> >
> >> > I'd like to start a vote for it. The vote will be open for at least 72
> >> > hours(excluding weekends,until Jan 10, 12:00AM GMT) unless there is an
> >> > objection or an insufficient number of votes.
> >> >
> >> >
> >> >
> >> > [1]
> >> >
> >> >
> >> https://cwiki.apache.org/confluence/display/FLINK/FLIP-387%3A+Support+named+parameters+for+functions+and+call+procedures
> >> > [2] https://lists.apache.org/thread/bto7mpjvcx7d7k86owb00dwrm65jx8cn
> >> >
> >> >
> >> > Best,
> >> > Feng Jin
> >> >
> >>

Re: Re: [VOTE] FLIP-387: Support named parameters for functions and call procedures

[Hang Ruan]

+1 (non-binding)

Best,
Hang

Jingsong Li  于2024年1月10日周三 12:03写道：

> +1
>
> On Wed, Jan 10, 2024 at 11:24 AM Xuyang  wrote:
> >
> > +1(non-binding)--
> >
> > Best！
> > Xuyang
> >
> >
> >
> >
> >
> > 在 2024-01-08 00:34:55，"Feng Jin"  写道：
> > >Hi Alexey
> > >
> > >Thank you for the reminder, the link has been updated.
> > >
> > >Best,
> > >Feng Jin
> > >
> > >On Sat, Jan 6, 2024 at 12:55 AM Alexey Leonov-Vendrovskiy <
> > >vendrov...@gmail.com> wrote:
> > >
> > >> Thanks for starting the vote!
> > >> Do you mind adding a link from the FLIP to this thread?
> > >>
> > >> Thanks,
> > >> Alexey
> > >>
> > >> On Thu, Jan 4, 2024 at 6:48 PM Feng Jin 
> wrote:
> > >>
> > >> > Hi everyone
> > >> >
> > >> > Thanks for all the feedback about the FLIP-387: Support named
> parameters
> > >> > for functions and call procedures [1] [2] .
> > >> >
> > >> > I'd like to start a vote for it. The vote will be open for at least
> 72
> > >> > hours(excluding weekends,until Jan 10, 12:00AM GMT) unless there is
> an
> > >> > objection or an insufficient number of votes.
> > >> >
> > >> >
> > >> >
> > >> > [1]
> > >> >
> > >> >
> > >>
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-387%3A+Support+named+parameters+for+functions+and+call+procedures
> > >> > [2]
> https://lists.apache.org/thread/bto7mpjvcx7d7k86owb00dwrm65jx8cn
> > >> >
> > >> >
> > >> > Best,
> > >> > Feng Jin
> > >> >
> > >>
>

Re: Re: [VOTE] FLIP-387: Support named parameters for functions and call procedures

[Feng Jin]

Thank you all! Closing the vote. The result will be sent in a separate
email.

Best,
Feng Jin

On Wed, Jan 10, 2024 at 2:04 PM Hang Ruan  wrote:

> +1 (non-binding)
>
> Best,
> Hang
>
> Jingsong Li  于2024年1月10日周三 12:03写道：
>
> > +1
> >
> > On Wed, Jan 10, 2024 at 11:24 AM Xuyang  wrote:
> > >
> > > +1(non-binding)--
> > >
> > > Best！
> > > Xuyang
> > >
> > >
> > >
> > >
> > >
> > > 在 2024-01-08 00:34:55，"Feng Jin"  写道：
> > > >Hi Alexey
> > > >
> > > >Thank you for the reminder, the link has been updated.
> > > >
> > > >Best,
> > > >Feng Jin
> > > >
> > > >On Sat, Jan 6, 2024 at 12:55 AM Alexey Leonov-Vendrovskiy <
> > > >vendrov...@gmail.com> wrote:
> > > >
> > > >> Thanks for starting the vote!
> > > >> Do you mind adding a link from the FLIP to this thread?
> > > >>
> > > >> Thanks,
> > > >> Alexey
> > > >>
> > > >> On Thu, Jan 4, 2024 at 6:48 PM Feng Jin 
> > wrote:
> > > >>
> > > >> > Hi everyone
> > > >> >
> > > >> > Thanks for all the feedback about the FLIP-387: Support named
> > parameters
> > > >> > for functions and call procedures [1] [2] .
> > > >> >
> > > >> > I'd like to start a vote for it. The vote will be open for at
> least
> > 72
> > > >> > hours(excluding weekends,until Jan 10, 12:00AM GMT) unless there
> is
> > an
> > > >> > objection or an insufficient number of votes.
> > > >> >
> > > >> >
> > > >> >
> > > >> > [1]
> > > >> >
> > > >> >
> > > >>
> >
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-387%3A+Support+named+parameters+for+functions+and+call+procedures
> > > >> > [2]
> > https://lists.apache.org/thread/bto7mpjvcx7d7k86owb00dwrm65jx8cn
> > > >> >
> > > >> >
> > > >> > Best,
> > > >> > Feng Jin
> > > >> >
> > > >>
> >
>

Re: [DISCUSS] FLIP-406: Reorganize State & Checkpointing & Recovery Configuration

[Zakelly Lan]

Hi Hangxiang,

Thanks for your suggestions!

1. Could execution.recovery also contain some other behaviors about
> recovery ? e.g. restart-strategy.


That's a very good point. I realize that the word 'recovery' means way too
many things. So I suggest picking a more specific word here, how about
'execution.state-recovery.*' ? Checkpointing and state recovery are
corresponding terms and won't make ambiguity.

2. Could we also remove some legacy configuration value ? e.g. LEGACY Mode
> for execution.savepoint-restore-mode/execution.recovery.claim-mode.


I think we could create another FLIP for the deprecation of LEGACY mode.


> 3. Could the local checkpoint be cleaned
> if execution.checkpointing.local-copy.enabled is true and
> execution.recovery.from-local is false ? I found it's also an issue if
> current local-recovery from enabled to disabled. Maybe another ticket is
> needed.


IIUC, there is no clear ownership of the local copy files from the previous
job and it's better to define one. This needs more discussion so we could
create another thread for this. WDYT?


Best,
Zakelly

On Tue, Jan 9, 2024 at 11:23 AM Hangxiang Yu  wrote:

> Hi, Zakelly.
> Thanks for driving this. Overall LGTM as we discussed offline.
>
> Some comments/suggestions just came to mind:
> 1. Could execution.recovery also contain some other behaviors about
> recovery ? e.g. restart-strategy.
> 2. Could we also remove some legacy configuration value ? e.g. LEGACY Mode
> for execution.savepoint-restore-mode/execution.recovery.claim-mode.
> 3. Could the local checkpoint be cleaned
> if execution.checkpointing.local-copy.enabled is true and
> execution.recovery.from-local is false ? I found it's also an issue if
> current local-recovery from enabled to disabled. Maybe another ticket is
> needed.
> 4. +1 for enabling execution.checkpointing.incremental by default which is
> basically default configuration in our production environment.
>
>
> On Mon, Jan 8, 2024 at 6:06 PM Zakelly Lan  wrote:
>
> > Hi Yun,
> >
> > Thanks for your comments!
> >
> >  1.  We shall not describe the configuration with its implementation for
> > > 'execution.checkpointing.local-copy.*' options, for hashmap
> > state-backend,
> > > it would write two streams and for Rocksdb state-backend, it would use
> > > hard-link for backup. Thus, I think
> > > 'execution.checkpointing.local-backup.*' looks better.
> >
> > I agreed that we'd better name the option in user's perspective instead
> of
> > the implementation, thus I name it as a copy of the checkpoint in the
> > local disk, regardless of the way of generating it. The word 'backup' is
> > also suitable for this case, so I agree to change to
> > 'execution.checkpointing.local-backup.*' if no one objects.
> >
> >  2.  What does the 'execution.checkpointing.data-inline-threshold' mean?
> It
> > > seems not so easy to understand.
> >
> > The 'execution.checkpointing.data-inline-threshold' (original one as
> > 'state.storage.fs.memory-threshold') stands for the size threshold below
> > which state chunks will store inline with the metadata, thus I call it
> > 'data-inline-threshold'.
> >
> >
> > Best,
> > Zakelly
> >
> > On Mon, Jan 8, 2024 at 10:09 AM Yun Tang  wrote:
> >
> > > Hi Zakelly,
> > >
> > > Thanks for driving this topic. I have two concerns here:
> > >
> > >   1.  We shall not describe the configuration with its implementation
> for
> > > 'execution.checkpointing.local-copy.*' options, for hashmap
> > state-backend,
> > > it would write two streams and for Rocksdb state-backend, it would use
> > > hard-link for backup. Thus, I think
> > > 'execution.checkpointing.local-backup.*' looks better.
> > >   2.  What does the 'execution.checkpointing.data-inline-threshold'
> mean?
> > > It seems not so easy to understand.
> > >
> > > Best
> > > Yun Tang
> > > 
> > > From: Piotr Nowojski 
> > > Sent: Thursday, January 4, 2024 22:37
> > > To: dev@flink.apache.org 
> > > Subject: Re: [DISCUSS] FLIP-406: Reorganize State & Checkpointing &
> > > Recovery Configuration
> > >
> > > Hi,
> > >
> > > Thanks for trying to clean this up! I don't have strong opinions on the
> > > topics discussed here, so generally speaking +1 from my side!
> > >
> > > Best,
> > > Piotrek
> > >
> > > śr., 3 sty 2024 o 04:16 Rui Fan <1996fan...@gmail.com> napisał(a):
> > >
> > > > Thanks for the feedback!
> > > >
> > > > Using the `execution.checkpointing.incremental.enabled`,
> > > > and enabling it by default sounds good to me.
> > > >
> > > > Best,
> > > > Rui
> > > >
> > > > On Wed, Jan 3, 2024 at 11:10 AM Zakelly Lan 
> > > wrote:
> > > >
> > > > > Hi Rui,
> > > > >
> > > > > Thanks for your comments!
> > > > >
> > > > > IMO, given that the state backend can be plugably loaded (as you
> can
> > > > > specify a state backend factory), I prefer not providing state
> > backend
> > > > > specified options in the framework.
> > > > >
> > > > > Secondly, the incremental checkpoint is actually a sharing file
> >

[RESULT][VOTE] FLIP-387: Support named parameters for functions and call procedures

[Feng Jin]

Hi devs,

I'm happy to announce that FLIP-387: Support named parameters for functions
and call procedures [1] [2]
 has been accepted with 6 approving votes (4 binding)

 - Benchao Li (binding)
 - Lincoln Lee (binding)
 - Timo Walther (binding)
 - Xuyang (non-binding)
 - Jingsong Li (binding)
 - Hang Ruan (non-binding)

There are no disapproving votes.

Thanks again to everyone who participated in the discussion and voting.

[1]
https://cwiki.apache.org/confluence/display/FLINK/FLIP-387%3A+Support+named+parameters+for+functions+and+call+procedures
[2] https://lists.apache.org/thread/m3hw5cc1ovtvvplv9hpd56fzzl44xxcr


Best,
Feng Jin