Remove biased annotations from prometheus.service.annotations

coredns / helm

Helm Charts for CoreDNS

Apache License 2.0

108 stars 111 forks source link

Remove biased annotations from prometheus.service.annotations #158

Open den-is opened 10 months ago

den-is commented 10 months ago

Why is this pull request needed and what does it do?

Makes the default prometheus.service.annotations blank {} map. Removing any bias.

Which issues (if any) are related?

Fixes https://github.com/coredns/helm/issues/157

Checklist:

[x] I have bumped the chart version according to versioning.
[x] I have updated the chart changelog with all the changes that come with this pull request according to changelog.
[x] Any new values are backwards compatible and/or have sensible default.
[x] I have signed off all my commits as required by DCO.

Changes are automatically published when merged to main. They are not published on branches.

Note on DCO

If the DCO action in the integration test fails, one or more of your commits are not signed off. Please click on the *Details* link next to the DCO action for instructions on how to resolve this.

hagaibarel commented 10 months ago

This would potentially break exiting installations that rely on this values being set by default

den-is commented 10 months ago

@hagaibarel correct. well, c'est la vie. But this is easy to fix for anyone. Currently I'm kinda fixing my setup for myself too, by providing null and I could ignore the "issues" completely. I just wanted to make this chart for the community better. Otherwise for how long are you going to haul this """not-that-smart""" non-standard piece in values.yaml?

hagaibarel commented 10 months ago

c'est la vie

This isn't my preferred way of maintaing an OSS project where we have a community and users to support. If we wanted to introduce a change that would break people's exiting installation, this should have been a major version release, not a patch (or even a minor).

Otherwise for how long are you going to haul this """not-that-smart""" non-standard piece in values.yaml?

Given that there isn't a "standard" in values file, it's common to provide sane defaults with an option to override / change them.

Bottom line, I don't think this change has any meaningful value

den-is commented 10 months ago

added comment to the issue. I can bump chart version to 2.0.0

hagaibarel commented 10 months ago

I don't think this change justifies bumping a major version, nor has any significant value.

There is an option to override the annotations if needed, and the defaults make sense and fit most use cases.

den-is commented 10 months ago

The override option is not functioning 100% as one would think by default and is not covering all cases.

hagaibarel commented 10 months ago

Can you provide a real world use case from your experience where overriding didn't address the issue?

den-is commented 10 months ago

Can you provide a real world use case from your experience where overriding didn't address the issue?

I have provided exact example in the original issue linked to this PR. Real world fact is that maps in Helm are not overridden but merged.