Provide default images and volume mounts to user-provided init containers #1022
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
nkvoll
requested review from
artemnikitin,
barkbay,
idanmo,
pebrc,
sebgl and
thbkrkr
as code owners
…ners.
This makes the user-provided init containers run after our built-ins,
meaning the user-provided init containers gets the final say on what
the environment is going to look like.
It defaults the init container image to the ES container image for convenience.
The Volume mounts for the ES container is appended to the init containers
volume mounts, with the result being that a simple init container will
run in the same context as Elasticsearch (with a notable exception of
environment variables)
This change facilitates use cases such as installing custom plugins:
```yaml
apiVersion: elasticsearch.k8s.elastic.co/v1alpha1
kind: Elasticsearch
metadata:
name: elasticsearch-sample
spec:
version: "7.1.0"
nodes:
- podTemplate:
spec:
initContainers:
- name: install-plugins
command:
- sh
- -c
- |
bin/elasticsearch-plugin install --batch repository-azure
nodeCount: 1
```
nkvoll
force-pushed
the
facilitate-custom-init-containers
branch
from
83e3959 to
2c0af65
Compare
sebgl
approved these changes
Jun 10, 2019
| // - If the init container contains an empty image field, it's inherited from the main container. | ||
| // - VolumeMounts from the main container are added to the init container VolumeMounts, unless they would conflict | ||
| // with a specified VolumeMount (by having the same VolumeMount.Name or VolumeMount.MountPath) | ||
| func (b *PodTemplateBuilder) WithInitContainerDefaults() *PodTemplateBuilder { |
There was a problem hiding this comment.
I think it would be safe to execute this as part of PodTemplateBuilder.setDefaults(), to enforce it for ES, Kibana & APM without the need to call it explicitly. What do you think?
There was a problem hiding this comment.
Unfortunately, this needs to happen /after/ the Volumes and VolumeMounts have been included.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This makes the user-provided init containers run after our built-ins,
meaning the user-provided init containers gets the final say on what
the environment is going to look like.
It defaults the init container image to the ES container image for convenience.
The Volume mounts for the ES container is appended to the init containers
volume mounts, with the result being that a simple init container will
run in the same context as Elasticsearch (with a notable exception of
environment variables)
This change facilitates use cases such as installing custom plugins:
TODO (to file issue upon merging)