Docker copy before env and respect JAVA_OPTS#11364
Conversation
distribution/docker/druid.sh
Outdated
There was a problem hiding this comment.
this probably needs a mention in the release notes, since it might have some backwards compatibility implications.
There was a problem hiding this comment.
also probably worth adding a comment to explain the ordering.
There was a problem hiding this comment.
Updated with comment.
Currently if you provide a config file it negates any settings set via environment variables. This change allows use of a config file as a base and allow environment variables to override. Additionally this allows dynamic features such as DRUID_SET_HOST to function correctly when a config file has been provided.
josephglanville
force-pushed
the
docker-copy-before-env
branch
from
d0bacd8 to
d745a71
Compare
|
@xvrl could I get another review of this PR? |
jihoonson
left a comment
jihoonson
left a comment
There was a problem hiding this comment.
LGTM. @josephglanville can you add a section in the PR description that the release manager can use? It will make the life of release manager easier. It would be nice if it mentions potential compatibility issues.
|
@jihoonson thanks for the review! I have updated the description with something I think would be adequate for inclusion in the release notes. |
|
@josephglanville the updated description LGTM. Thanks! |
6 participants
This PR introduces two changes to how Druid services are started within the Docker image.
The first changes the behavior of environment variables defined using the
druid_prefix style.Previously these settings were disregarded when using a config file specified using
DRUID_CONFIG_${service}, in effect they were ignored.With this change environment variables when combined with
DRUID_CONFIG_${service}will override the settings in the config file.The second influences how runtime JVM configuration is calculated when using the Docker image.
Prior to this change settings in a services
jvm.configwere specified afterJAVA_OPTSon the Java command line when starting the service.This meant that when a flag is present in both
jvm.configandJAVA_OPTSthe setting fromjvm.configwould take precedence, this change reverses this relationship withJAVA_OPTSnow being specified after flags sourced fromjvm.config