Add functionality to allow configuring the loglevel the operator is deployed with in the Helm chart#489
Open
soenkeliebau wants to merge 1 commit intomainfrom
Open
Add functionality to allow configuring the loglevel the operator is deployed with in the Helm chart#489soenkeliebau wants to merge 1 commit intomainfrom
soenkeliebau wants to merge 1 commit intomainfrom
Conversation
…eployed with in the Helm chart.
This introduces a variable called 'logLevel' which, when set to an empty string is not propagated to the deployment by the Helm chart at all, so that the default value for the loglevel in the operator code remains effective.
When set to a non-empty string the value is propagated as environment variable <PRODUCTNAME>_OPERATOR_LOG into the pod template of the operator deployment.
Additionally this adds code to the Tiltfile that allows configuring this via a local override, in a similar fashion to what we already allow for the default registry.
Users can create a file called `tilt_options.json` and in there define a loglevel as follows:
{
"loglevel": "DEBUG"
}
When this file is present the value from here will be read and passed to the Helm chart by Tilt. If this file is not present, an empty string is passed through, triggering the behavior described above where the default loglevel defined in the operator code remains effective.
This PR doesn't introduce a default for the 'logLevel' variable in the Helm charts, as the values.yaml files are not managed by templating. However adding a default for that variable should be an optional step, that we can do later at our convenience, or totally omit.
Member
|
I'm fine with this, as I asked the question that triggered it and have tested it locally, but would be happy to let others approve (or not). |
Member
Author
|
I'd say, lets definitely wait until release branches have been cut with this. |
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
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 introduces a variable called 'logLevel' which, when set to an empty string is not propagated to the deployment by the Helm chart at all, so that the default value for the loglevel in the operator code remains effective.
When set to a non-empty string the value is propagated as environment variable _OPERATOR_LOG into the pod template of the operator deployment.
Additionally this adds code to the Tiltfile that allows configuring this via a local override, in a similar fashion to what we already allow for the default registry.
Users can create a file called
tilt_options.jsonand in there define a loglevel as follows:{ "loglevel": "DEBUG" }When this file is present the value from here will be read and passed to the Helm chart by Tilt. If this file is not present, an empty string is passed through, triggering the behavior described above where the default loglevel defined in the operator code remains effective.
This PR doesn't introduce a default for the 'logLevel' variable in the Helm charts, as the
values.yamlfiles are not managed by templating. However adding a default for that variable should be an optional step, that we can do later at our convenience, or totally omit, since an unset value will just fall through to the default loglevel from code again.