sap1ens opened a new pull request, #370:
URL: https://github.com/apache/flink-kubernetes-operator/pull/370
## What is the purpose of the change
Allowing to use job jars located in the system classpath (e.g.
`/opt/flink/lib`). Currently it's not possible.
## Brief change log
- Making `spec.job.jarURI` optional, removing validation.
- Updating `FlinkConfigBuilder` to not define `pipeline.jars` and
`pipeline.classpaths` if the `jarURI` is not specified.
- Updating `UserLibMountDecorator` to not create a `usrlib` folder if
`pipeline.classpaths` is not defined. Otherwise Flink will try to load the
provided class from the `usrlib` folder which is empty.
## Verifying this change
This change added tests and can be verified as follows:
- Running updated tests: `DefaultValidatorTest`, `FlinkConfigBuilderTest`,
`UserLibMountDecoratorTest`.
- I've also deployed an operator with a custom Docker image built based on
this branch to a staging environment. I confirmed that my custom Flink Docker
image with a job jar in `/opt/flink/lib` can be executed successfully.
## Does this pull request potentially affect one of the following parts:
- Dependencies (does it add or upgrade a dependency): no
- The public API, i.e., is any changes to the `CustomResourceDescriptors`:
no, but it does make a required parameter optional
- Core observer or reconciler logic that is regularly executed: no
## Documentation
- Does this pull request introduce a new feature? yes
- If yes, how is the feature documented? docs
---
**NOTE**: I find `UserLibMountDecorator` implementation a bit weird. It
looks like right now `/opt/flink/usrlib` is always created in the Application
mode. The class comments mention `pipeline.classpaths`, but it seems like the
classpaths specified this way can be located anywhere. [Flink's
DefaultPackagedProgramRetriever explicitly
adds](https://github.com/apache/flink/blob/40d50f177c8ac63057dea2c755173a0dc138ede5/flink-clients/src/main/java/org/apache/flink/client/program/DefaultPackagedProgramRetriever.java#L104-L110)
`usrlib` and `pipeline.classpaths` separately. In my opinion, the operator
should let the user create `usrlib` if needed. It's not in the scope of this
PR, but I'm happy to create a follow-up issue.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@flink.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
