-
Notifications
You must be signed in to change notification settings - Fork 505
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding a config.toml value to the helm chart #1420
Closed
Closed
Changes from 3 commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,14 @@ | ||
{{- if .Values.configToml.enabled -}} | ||
apiVersion: v1 | ||
kind: ConfigMap | ||
metadata: | ||
name: {{ template "fullname" . }}-configtoml | ||
labels: | ||
app: {{ template "fullname" . }} | ||
chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" | ||
release: "{{ .Release.Name }}" | ||
heritage: "{{ .Release.Service }}" | ||
data: | ||
config.toml: |- | ||
{{ .Values.configToml.data }} | ||
{{- end -}} |
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
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
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
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.
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.
Do you prefer
enabled
-switch approach?Why not to just always use this config, without any conditions? I guess the default values should be fine, so we can leave it empty as you did. If not, we can provide some useful settings, maybe from https://github.com/gomods/athens/blob/master/config.dev.toml but still always mouning the config to the container.
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.
@hypnoglow I set
enabled: false
to keep the Kubernetes deployment the same, by default. So, unless someone wants to customize the config file, there won't be any new config map the next time they deploy.Regarding useful settings, the Athens image already has that config.dev.toml file baked into it. Is that what you were thinking?
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.
I mean we may omit
enabled
switch completely.The reason is that I suppose
config.dev.toml
serves only for documentation purposes, and it contains only values that are Athens defaults. Bundling this file into the image actually is the same as passing empty config.If I'm wrong and
config.dev.toml
contains some values that are not Athens default, we can simply put them here in the chart default values. This way we also don't needenabled
switch.For example:
So if users want to customize config, they will rewrite
configToml
with their value, otherwise they have the same defaults.enabled
switch is not needed in both cases.What do you think?
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.
@hypnoglow ah, I think I partially see now what you mean. Regarding the defaults, I would say that there are several "layers" of defaults.
There are hard-coded ones like here the embedded
config.dev.toml
one, and then the ones in the helmvalues.yaml
file. To be honest, I doubt the defaults in code match, the toml file and the helm values.yaml file all match up. However, there are reasons why we do have all three layers. I'm happy to explain them if you'd like or that would help 😄Regarding the overrides, are you saying that the
configToml:
key could have just part of a config toml file, and that we would use it to override the one that is embedded in the Athens docker image?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.
Ah, it's a bit clearer now, thanks for explanations. However, don't those multiple layers add unnecessary complexity to the overall Athens configuration? BTW I guess it is going a bit offtopic. If you believe we should stick to those "layers" for now and keep Helm chart in accordance, we should go with it then.
Yes, exactly. My point was that we can use default config options directly in helm values that will always override embedded config.
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.
@hypnoglow I personally think they do, but there is a need for folks to customize configuration at each of the levels, and we have the defaults in place to show where to customize configuration.
For example, the Helm
values.yaml
is there show some examples of how folks can customize their Kubernetes deployment. Those fields get translated to environment values passed to Athens, however, so the configuration mechanism doesn't change from other deployments of Athens, for what that's worth 😄 .I do think we need to stick with the layers, and I'd like to see them documented (I just created an issue for that, and I'm planning to do it today).
I agree that ideally the helm values.yaml file should be up to date with the config.dev.toml and the hard-coded defaults, and we can try to do that, but inevitably they will become out of sync. I am going to try to write documentation clear enough that folks can both understand where the layers are, how to read each one (config.toml, values.yaml, etc...), and that they may diverge.
The merging option is interesting, but wouldn't someone set environment variables or provide a
values.yaml
file if they want to override just part of theconfig.toml
file? This PR is intended to allow people to override everything at once.Let me know what you think, and thank you for the discussion!
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.
@arschles Thank you for your efforts on improving documentation.
I believe that we can try to reduce layers complexity, somewhat like this:
config.toml
or environment variables provided by user.config.toml
with only docker-specific options tuned, if it is even required. Custom configuration should be provided asconfig.toml
-volume or environment variables by user.values.yaml
or similar and allowing to be customized by user.This way users will always know that they get the same configuration, whether they running Athens standalone, in Docker or in Kubernetes.
I didn't mean merging. To recap what I suggested:
If we use
enabled
-switch approach, then withenabled: false
helm chart runs with Docker-builtinconfig.toml
and custom configuration can be passed only with environment variables. Withenabled: true
we completely override Docker-builtinconfig.toml
file with contents indata
key. In this approach,configToml.data
contains no default configuration, and users settingenabled: true
will not know that this will override default Docker-builtin config completely and consequences.If we don't use
enabled
switch, thenconfigToml
contents ALWAYS override Docker-builtinconfig.toml
, so users don't even have to know about that config file built in the docker image. This way we can embed default configuration for Helm deployment directly intovalues.yaml
, and it always get injected. If user needs to change it, they can add/remove configuration options in their customvalues.yaml
-file.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.
@hypnoglow you're welcome
This is working now. You can use the
-config_file
flag (we will need to document that)We would need to them remove the current
config.toml
file from the docker image, which will cause backward compatibility issues. And that is the root problem we will need to solve.Would it be helpful for Athens to have an environment variable like
CONFIG_FILE
:/path/to/file.toml
to tell Athens to read from a specific config file. you can already pass it the-config_file
flag, but that is more difficult when running in a docker containeroff
to tell Athens to completely ignore the config file and go with hard-coded defaults and environment variablesWe still will need to keep the default
config.toml
in the docker image, but we can also make it easier here to mount your own config.toml file or turn it offWhat do you think?
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.
(P.S. I'll respond much more quickly this time. I have far less travel this year 😄)