Fix docker positional params (take 2)#88584
Merged
pugnascotia merged 5 commits intoelastic:masterfrom Jul 19, 2022
Merged
Conversation
As part of elastic#50277, we removed the `TAKE_FILE_OWNERSHIP` option from the Docker entrypoint script and the associated chroot calls, and instead just defaulted to running the image as `elasticsearch` instead of `root`. However, we didn't check that it was still possible to pass CLI options to Elasticsearch via CLI arguments, and broke this by mistake. This is probably an uncommon pattern, versus environment variables or a config file. Nevertheless, it is supposed to be possible and is mentioned in the documentation. Fix the problem by suppling the missing positional params when calling Elasticsearch, and add a test case so that we don't break it again.
Collaborator
|
Pinging @elastic/es-delivery (Team:Delivery) |
Collaborator
|
Hi @pugnascotia, I've created a changelog YAML for you. |
Contributor
If I recall, this is partly intentional because of the issue of downloading beats after a version bump. If we integrated cloud image testing into all PR testing, folks would be blocked until a successfull snapshot was published. I think we can revisit this once we are consuming the DRA artifacts for beats. |
mark-vieira
approved these changes
Jul 18, 2022
pugnascotia
added a commit
that referenced
this pull request
Jul 19, 2022
As part of #50277, we removed the `TAKE_FILE_OWNERSHIP` option from the Docker entrypoint script and the associated chroot calls, and instead just defaulted to running the image as `elasticsearch` instead of `root`. However, we didn't check that it was still possible to pass CLI options to Elasticsearch via CLI arguments, and broke this by mistake. This is probably an uncommon pattern, versus environment variables or a config file. Nevertheless, it is supposed to be possible and is mentioned in the documentation. Fix the problem by suppling the missing positional params when calling Elasticsearch, and add a test case so that we don't break it again.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
Follow-up to (and re-apply of) #88502, which we had to revert.
The change itself was good, but it turned out that the test we added only applies to non-Cloud images. This is because for the Cloud images, the
ENTRYPOINTandCMDare different, such that defining theELASTIC_PASSWORDdoesn't set theelasticuser's password. Since Cloud currently assumes control of image startup, there's little point working around this in the test since we have no control over what's happening at runtime in production.@mark-vieira note that we didn't catch this during PRs, because we only run the
destructiveDistroTest.dockertask in CI, which only tests the default image. We only test all the Docker images on merged changes. What do you think about reworking this, so that we get better coverage when we're explicitly testing packaging changes?