Is it better to create a Jira issue for this? From what I can tell it is currently not possible to use native k8s mode while having the jar in the system classpath. This seems like something that would generally be useful in order to avoid dynamic classloading when using the operator.
On Mon, Nov 27, 2023 at 5:50 PM Trystan <entro...@gmail.com> wrote: > 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? >>>>> >>>>
