Hi Flyte Community, is JFlyte compatible with spring boot applications?

Cc @Guillaume Perchais / @Nelson Arapé / @honnix / @Sonja Ericsson

Unless there is some dependency conflict, it is an ordinary Java library not bound to any framework. So most likely it is compatible.

JFlyte takes in JARs and uses the Java Service Loader, which expects files such as the following to exist: •

META-INF/services/org.flyte.flytekit.SdkWorkflow

•

META-INF/services/org.flyte.flytekit.SdkRunnableTask

Spring boot applications typically generate jars that store these files under a BOOT-INF directory: •

BOOT-INF/classes/META-INF/services/org.flyte.flytekit.SdkWorkflow

•

BOOT-INF/classes/META-INF/services/org.flyte.flytekit.SdkRunnableTask

I'm concerned that attempting to manually jar the files differently might break the Spring application setup. Would the suggested workaround be to update the JFlyte code to look within the

BOOT-INF/classes

path instead of the root JAR path?

I unfortunately don't think that is a reasonable ask because it is spring-boot specific, and an ordinary service loader (https://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html) will not be able to read files under that location. I'm not a spring-boot user so I don't know whether that is really a hard requirement.

If JFlyte is not compatible with Spring boot applications, would the suggested workaround be to create a raw Docker image with an entrypoint to the spring boot application itself (https://docs.flyte.org/projects/cookbook/en/latest/auto/core/containerization/raw_container.html)? Does JFlyte support defining raw container tasks (or would I need to define these in python)? Are there potential performance concerns with this approach?

Raw containers cannot today support streaming data and very fast exits may take longer as it depends on watching processes

Hi Ketan, thank you for calling this out. What are fast exits (and is there some way to workaround the issue of slower exits)? How does JFlyte optimize this performance?

Like if the container starts and exits immediately it may be possible that the copilot container misses this process

Hi Ketan, I'm still working on mapping the task to configmaps in the namespace but will let you know if I see any issues. Is there something that we can do to avoid the edge case you've mentioned?

Ohh it won’t be a bug, it will eventually exit 30sec delay in the worst case

Got it, thanks for clarifying!