Hi, Matthias
Thanks a lot for joining the discussion.
> Generally, netty upgrades are a source of instability based on past
experiences. But considering that we have newer versions (4.1.91.Final)
tested with flink-shaded 17.0 in Flink 1.18, it should be alright bumping
netty in flink-shaded 16.2
IHi Yuxin,
That would be the way to go for flink-shaded and Flink 1.17.
Generally, netty upgrades are a source of instability based on past
experiences. But considering that we have newer versions (4.1.91.Final)
tested with flink-shaded 17.0 in Flink 1.18, it should be alright bumping
netty in fl
Hi, devs,
I would like to revive the discussion again.
In our ARM environment, we encounter a compile error when
using Flink 1.17.
Flink 1.17 depends on flink-shaded 16.1, which uses netty 4.1.82.
However, flink-shaded 16.1 fails to compile in the ARM
environment. As a result, we are unable to c
Hi Chesnay,
Thanks for joining this discussion and sharing your thoughts!
> Connectors shouldn't depend on flink-shaded.
>
Perfect! We are on the same page. If you could read through the discussion,
you would realize that, currently, there are many connectors depend on
flink-shaded.
> Connect
There is no "monolithic" flink-shaded dependency.
Connectors shouldn't depend on anything that Flink provides, but be
self-contained as Martijn pointed out.
Connectors shouldn't depend on flink-shaded.
The overhead and/or risks of doing/supporting that right now far
outweigh the benefits.
( Be
Hi Sergey,
Thanks for sharing your thoughts. It could somehow help but didn't get to
the root of this issue.
According to the documentation, Flink shaded is used to provide a single
instance of a shaded dependency across sub-modules in Flink repo. Shaded
namespaces should be used where shaded dep
Yes, that's a reasonable question, thanks for raising it.
I think this is not only about flink-shaded, rather about dependencies in
general
I guess there is no rule of thumb, or at least I'm not aware of
Here are my thoughts
1. If bumping dependency doesn't require breaking changes and passes
exi
Hi Sergey,
Thanks for doing the analysis and providing the great insight. I did my own
analysis and got the same conclusion. I just wanted to use this example to
kick off a discussion and check if there is a common guideline or concept
in the community to handle such cases, since it seems any bump
Thanks for raising this
I would suggest trying to double check whether it actually impacts Flink or
not.
For instance from one side Calcite between 1.22.0..1.31.0 has a critical
CVE-2022-39135 [1]
from another side Flink does not use this functionality and is not impacted
by this.
Regarding guav
Hi Sergey, Hi Martijn,
Thanks for the information and suggestions. It is rational.
Since on one hand, we should not do the upgrade according to all your
thoughts, and on the other hand, Guava 30.1.1-jre has known CVEs[1] and the
next closest version that has no CVEs is 32.0.1-jre. Without the upg
Hi Jing,
Like Sergey said, making that change would break all connectors that used
Flink Shaded in the released versions, given that Guava is part of the
package name. I think that was the case for Kafka, Pulsar, JDBC, PubSub,
HBase, Cassandra and maybe even more. We shouldn't do this upgrade.
Be
Hi Jing,
If I remember correctly, bumping of guava to another major version usually
leads to package rename
since the major version number is a part of the package name...
Not 100% sure however this could be the reason for some potential breaking
changes (we also faced that with connectors while t
Hi Martijn,
For example, bump up guava from 30.1.1-jre to 32.1.2-jre.
Best regards,
Jing
On Wed, Sep 13, 2023 at 2:37 PM Martijn Visser
wrote:
> Hi Jing,
>
> A PR to update the readme sounds like a good plan.
>
> I think it depends on what are the expected updates for a flink-shaded
> 16.2, si
Hi Jing,
A PR to update the readme sounds like a good plan.
I think it depends on what are the expected updates for a flink-shaded
16.2, since that version doesn't exist.
Best regards,
Martijn
On Wed, Sep 13, 2023 at 1:48 PM Jing Ge wrote:
> Hi Martijn,
>
> Thanks for your reply with details
Hi Martijn,
Thanks for your reply with details. Appreciate it.
> Flink-Shaded is usually only updated whenever a
> new Flink minor version is released and only at the beginning of the
> release cycle, so that there's enough time to stabilize Flink.
This is the information I am looking for. It
Hi Jing,
Flink Shaded exists so that Flinks internal usage of commonly used packages
such as Guava, Jackson inside of Flink don't clash with different versions
that users might use when creating a Flink application. When I did the
upgrade of Flink Shaded, we already ran into a bunch of problems be
16 matches
Mail list logo
