-
Notifications
You must be signed in to change notification settings - Fork 30
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
chore: Helm chart reconfiguration #408
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Lucas Fontes <[email protected]>
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'd like to drop the wadm
key from config entirely, adding that in this chart was a mistake in the first place, it really needs to be left up to the charts to that might include this chart as a subchart.
I think the ⚖️ here is that there are a bunch of examples out there (docs, other repos) that reference this current format in the helm values file they use to deploy wadm, which means that if we go ahead and drop the key, we'll want to make sure that all of those references are also updated with it.
The same would apply if we went ahead and renamed the key this way as well, but it's something to keep in mind as we publish this
podSecurityContext: | ||
{} |
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.
Would you mind reverting this so it's in line with the rest of the map-based entries?
Or alternatively would you mind going ahead and changing the rest of the empty map entries to match this style?
I'm not sure which format should be preferred to be honest, though Helm defaults to podSecurityContext: {}
over this
resources: | ||
{} |
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.
Would you mind reverting this so it's in line with the rest of the map-based entries?
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.
no problem. heads up this is literally the output from yaml linter
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.
Fair enough, it looks like it doesn't touch these values when they are grouped next to other values, so maybe it's worth pulling them up into a group above?
Strange behavior on the linter's part to be honest, but what can you do 🙂
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this has been closed too eagerly, please feel free to tag a maintainer so we can keep working on the issue. Thank you for contributing to wasmCloud! |
I think this is a valid change still, not sure if you wanted to try to bring this up to date with the latest chart version so we can maybe get it merged in? |
Changing
wadm
andconfig
positions in values.yamlWhen bringing in wadm as a subchart, the resulting values.yaml stutters. Ex:
Further example in wasmCloud/wasmCloud-contrib#19
Increasing release from
0.2.5
to0.3.0
due to this config change.Templating in
nats.server
Allows dynamic values, helpful in automated installs. Example: