Thanks! Yeah I am not sure why it's handled so different with non-native k8s mode.
If it's possible I think this would be a huge improvement. On Mon, Nov 20, 2023, 12:55 PM Alexis Sarda-Espinosa < sarda.espin...@gmail.com> wrote: > Hi Trystan, I'm actually not very familiar with the operator's internals, > but I'd guess that limitation is in Flink itself - application mode is a > feature from core Flink, the operator just configures it based on the CRDs > it defines. Maybe one of the maintainers can confirm. > > Regards, > Alexis. > > On Mon, 20 Nov 2023, 19:25 Trystan, <entro...@gmail.com> wrote: > >> Thanks Alexis, I can give that a try. However, that seems less than ideal >> from the user's perspective. >> >> Is there a technical reason why the operator can't support this >> combination of modes? I'd really like to just let the system do its thing >> rather than build a complicated two-jar approach. >> >> Thanks, >> Trystan >> >> On Fri, Nov 17, 2023 at 12:19 PM Alexis Sarda-Espinosa < >> sarda.espin...@gmail.com> wrote: >> >>> Hi Trystan, >>> >>> I imagine you can create 2 jars, one should only have a class with the >>> main method, and the other should be a fat jar with everything else for >>> your job. If you create a custom image where your fat jar is placed under >>> /opt/flink/lib/ then I think it would "just work" when specifying the >>> main-method jar in jarURI. >>> >>> Nevertheless, even though Flink shadows a lot of the libraries they use >>> internally, I suppose you could still end up with dependency conflicts, so >>> you would probably have some added complexity managing what's bundled in >>> your fat jar. >>> >>> Regards, >>> Alexis. >>> >>> Am Do., 16. Nov. 2023 um 19:42 Uhr schrieb Trystan <entro...@gmail.com>: >>> >>>> Is it possible to avoid dynamic classloading when using the operator >>>> with a native kubernetes application deployment? >>>> >>>> If I put the job jar into /opt/flinklib, then there are two possible >>>> outcomes: >>>> >>>> 1. If I point jarURI to the jar, I get linkage errors (presumably: >>>> the class have already been loaded by the AppClassLoader and the >>>> FlinkUserCodeClassLoader). >>>> 2. If I do not include jarURI the operator pods encounter a >>>> NullPointerException. The docs state this is optional, but appears to >>>> only >>>> pertain to standalone mode. >>>> >>>> https://issues.apache.org/jira/browse/FLINK-29288 enabled the optional >>>> jarURI (apparently only for standalone deployments). >>>> >>>> Are there any additional configurations (configs, jar locations, etc) >>>> that are needed to avoid dynamic classloading in this case? >>>> >>>
