-
-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow adding postStartScript lifecycle hook to all deployments #206
Conversation
7213fdf
to
54be0a1
Compare
This comment has been minimized.
This comment has been minimized.
d395890
to
59c3600
Compare
This comment has been minimized.
This comment has been minimized.
f411b85
to
9e45053
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
cab5ed1
to
1278eb5
Compare
Hmm. I should probably add a checksum annotation that covers the configmap template and the |
20b5e02
to
98216e9
Compare
@armab edit: please checkout #219 next, which was separated from this PR
You might want to checkout the k8s docs in the PR description. :) |
5dcb27c
to
4b439dc
Compare
f7eb0af
to
fe6ea12
Compare
fe6ea12
to
746845e
Compare
I think it will solve one of the use cases that many requested, - installing packages for some of the st2 actions like, say, ansible instead of providing their own forked pre-baked image, both approaches with their pros/cons. Oerall any customization before starting the st2 cluster makes sense and brings a lot of configuration flexibility 👍 |
@armab I'm glad you like the idea |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice addition for customizing the ST2 cluster environment.
Thanks for that!
This builds on the postStart lifecycle hook from #219, but allows adding custom
postStartScript
(via values) to each deployment pod.In my old 1ppc-based st2 cluster, the entrypoint script had some cluster-specific
customizations. With the current docker images, we don't use an entrypoint script.
Some of those customizations do not translate well to cacheable Dockerfile commands.
The
postStart
lifecycle event provides something similar in that I can add thosecluster-specific customizations when I can't bake the changes directly into custom
docker images.
For example, in the actionrunner pods, I have a script that:
(the perl modules themselves are baked into the docker image).
And in the chatops pod, our image has a slightly customized version of hubot that
needs an additional config file. That config file should not be baked into the image.
We also use the init script for rapid testing of changes in our development st2 cluster
before we bake them into the docker images (where baking the changes in makes sense).
Though these could potentially be done via initContainers, adding custom initContainers
becomes much more complex when you consider the required additional volumes and volumeMounts.
see:
https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/
https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/