-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Conversation
Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually? |
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.
Had one question but the rest LGTM!
resources: | ||
requests: | ||
storage: 100M | ||
extraInitContainers: | |
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.
Could you explain why these extra init containers are needed for a kind deployment? The chart is already correctly setting the permissions and the elasticsearch process should be creating those directories.
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.
@Crazybus yeah.. that is needed for KIND.. for some reason the container doesn't create that by default and the whole deployment was failing. You can give it a try and see if you find the reason why the container is failing to do so.. I couldn't see anything in the logs except for an exception saying that it didn't had access to write the files in the /usr/share/elasticsearch/data/nodes/
directory. Once the directory is created, everything works as expected.
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.
Thanks, I'll certainly give it a go to see if I can reproduce it. Seems like a bit of a shame that kind doesn't seem to be compatible with the way that normal kubernetes works though :(. It makes sense that resources and node anti affinity need to be relaxed but this makes it impossible to properly test with kind.
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.
It should be super straight forward to reproduce it and find the cause if you can debug the ElasticSearch container. But for now that is needed.
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.
@Crazybus also I notice that for KIND this is required: storageClassName: "standard"
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.
Sorry that I haven't gotten around to testing this out just yet. Did you also try just leaving storageClassName
out completely? That should just use whatever the default is set to which is probably "standard"
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.
that is true.. I am removing that line completely
jenkins test this please |
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.
⛴
${CHART}/tests/*.py
${CHART}/examples/*/test/goss.yaml
This PR adds support for running elastic for development purposes on Kubernetes KIND (https://github.com/kubernetes-sigs/kind) which for some reason require the directory to be created before using it for elasticsearch data. Hence the use of an initContainer.