rudr
rudr copied to clipboard
oam-dev
Add initContainers support
Hi,
The actual implem (and spec) lacks initContainers support.
I think there is valid use-cases to add it:
- Stitching a lot of env variables in a settings file in a mounted volume between initContainer and Container.
- Download plugins in a shared volume before starting the app, the plugins list could be found in a param.
The workaround is to put all this init stuff in the entrypoint of the final container but I think it's backward of all best practices.
Stitching a lot of env variables ... Download plugins in a shared volume ...
Can't this be implemented as traits? Not to be too dogmatic. But this kind of work are defined as operations and reusable as traits
If we decide to implement this either in the spec or as a trait, please make the init behavior deterministic.
In the early version of Kubernetes, init container is expected to only execs when the pod is created (Exact Once). But in reality, it MAY execute when the pod restarts (restart machine) (at least once, but nondeterministic), and sometimes not (pod restart, but machine is not).
Now the expected behavior changes to exec init container every time the pod start/restart (at least once, but deterministic.)
I think we would have to do this as a trait, since once again not all of the implementations of OAM have initContainers. Adding it as a trait would also provide a good pattern for trait authors to follow.
I'm looking for a way that give an example of how traits in Rudr could be used widely, even in other implementation of OAM.
But initContainer is a feature coupled with K8s pod, it's easier and better to be implemented as the way like the traits we already have.
Maybe logging trait is a good start.
Should we open this as an issue on the spec repo?
I think we'll keep it in Rudr. InitContainer is a pretty useful best practice in K8s context.
I'd propose to model Pinterest Service as a starting PoC: an example to illustrate how to use OAM to model in-house app crd.
