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
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 i
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 M
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
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
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
