[stable/prometheus-operator] Bump prometheus-operator version to 0.41.0

[sev3ryn]

Is this a new chart

No

What this PR does / why we need it:

Bump docker image tags for

• prometheus
• prometheus-config-reloader

Update prometheus-operator CRDs to 0.41.0

Checklist

• DCO signed
• Chart Version bumped
• Title of the PR starts with chart name (e.g. [stable/mychartname])

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: sev3ryn
To complete the pull request process, please assign vsliouniaev
You can assign the PR to them by writing /assign @vsliouniaev in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• stable/prometheus-operator/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Hi @sev3ryn. Thanks for your PR.

I'm waiting for a helm member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[sev3ryn]

/assign @vsliouniaev

[mrueg]

@sev3ryn thanks for your PR!
A few comments:

• Can you also update configmap-reload image to v0.4.0 (changed in v0.41.0)?
• Can you include TLS support for prometheus-operator (added in v0.39.0)? This might allow us to deprecate the tlsProxy.

[sjentzsch]

Thanks for the PR! Looking forward to it. My concerns:

• need to add probes to prometheus-operator/clusterrole.yaml (why is there a duplicated entry of podmonitors? Could be a good opportunity to replace it)
• shouldn't we bump the version of the chart to a new major one? 10.x? From the release log of prometheus-operator, we now depend on "kubernetes v1.16 or newer", right?
• would be awesome to incorporate the clusterAdvertiseAddress now: Allow setting the alertmanagers cluster.advertiseAddress prometheus-operator/prometheus-operator#3160 (otherwise, I will file a MR)

[sev3ryn]

@mrueg I've bumped version of configmap-reload image. Regarding TLS support - maybe it worth doing it as separate PR, to not wait a long for probes support to be merged. What do you think?

Otherwise me how do you see adding TLS configs and values like tls-min-version, tls-cipher-suites - certs in a secret and other as helm values?

[mrueg]

Thanks! Sure, there can be a follow-up PR to support that as well. I think eventually cert/key should be in a secret similar to tlsProxy currently and the rest simply be values.

[sev3ryn]

@sjentzsch thanks for your findings,

fixed prometheus-operator/clusterrole.yaml

From the release log of prometheus-operator, we now depend on "kubernetes v1.16 or newer", right?

Yes, you are correct - you opened my eyes why this was not updated to v0.39.0 before :(
This will probably lead to lots of modifications, e.g. templates/prometheus/rules and hack will be no longer needed. What do you suggest to do? wouldn't it impact lots of chart users?

[sjentzsch]

@sev3ryn I would suggest to start the 10.x version, and add a note to the README. In my opinion, there is only one way to go (which is forward), and all proper chart users should pin the version anyway, so by opening a 10.x we should be fine. However, I am not one of the core maintainers, would be good to have another opinion too.
If we go that way, indeed, I would support removing templates/prometheus/rules and hack.

[sev3ryn]

@sjentzsch As I understand clusterAdvertiseAddress should be unique for each replica and this is not possible to do because templates/alertmanager/alertmanager.yaml you set values for all the replicas at once

[sjentzsch]

@sev3ryn Yes indeed, that would be an optional setting; by default it definitely has to be unset. It's just, I would require it for a use case I have (with alerting cluster spanned across two kubernetes clusters), thus I would need the option to set it. However, not necessarily within this MR.

[scottrigby]

/hold

Let’s hold PRs to prometheus-operator for a short time until prometheus-community/community#28 (comment) is resolved. If you want to help with that effort, to test etc, that would be great!

[scottrigby]

@sev3ryn (also @sjentzsch and @mrueg) as users and contributors, would you mind helping to review/test this PR? prometheus-community/helm-charts#1

No need to reply here. If you can, please just reply and help there. It would help this process move along faster. Thanks!

[scottrigby]

🚧 This chart is now deprecated.

Further development has moved to prometheus-community/helm-charts. The chart has been renamed kube-prometheus-stack to more clearly reflect that it installs the kube-prometheus project stack, within which Prometheus Operator is only one component.

If applicable, please re-open this PR there. Thanks!