Don't set global workqueue MetricsProvider

[austince]

Currently, controller-runtime sets the global workqueue MetricsProvider in an init method which makes it impossible for users of the library to configure their own.

As noted in:

• Allow non-global metrics factory for workqueues kubernetes/client-go#1193
• Allow setting per-workqueue metrics providers kubernetes/kubernetes#114242 (comment)
• SIG API meeting: https://docs.google.com/document/d/1x9RNaaysyO0gXHIr1y50QFbiL1x8OWnk2v3XnrdkT5Y/edit?pli=1#heading=h.41qdxxsr3sdz

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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.

[alvaroaleman]

I thought about this issue the other day and one possible approach that came to mind is that rather than using an init(), we could register these the first time a controller is created. This would:

• Not break any existing user who wants to just keep using the controller-runtime metrics
• Allow advanced users to set their own provider by doing that before they create a controller

[alvaroaleman]

@sbueringer made me aware that this might break a lot of existing users, because component-base also does this in an init and today controller-runtime happens to "win": https://github.com/kubernetes/component-base/blob/3b0f2cefb281ec6078f2949fe7041619ddcfd262/metrics/prometheus/workqueue/metrics.go#L104

[JoelSpeed]

Per a bug I was investigating this morning, you may not always win that race. Depending on your import graph, you may end up pulling in component-base earlier than controller-runtime and therefore, it executes the component-base version of this prior to the controller-runtime version, which means we lost.

A non-breaking way to do this would be to expose the metrics provider as a public object. I believe users now have access to create their own NewQueue implementation, which means they could pass the metrics provider into that. But currently, the metrics provider is all private. If this were public, could I not then explicitly pass it, causing the queue to leverage this provider over the global provider and avoiding any races?

[alvaroaleman]

Hmhm. I am wondering if rather than setting the global metric provider for the queues, we could set it only in the opts for the queues we construct if not already set? Then things will keep working for everyone without us having to snatch the global provider. The only case I can think of where that would cause issues is if someone constructs a queue themselves and relies on its metrics shown up in controller-runtime.

[JoelSpeed]

The only case I can think of where that would cause issues is if someone constructs a queue themselves and relies on its metrics shown up in controller-runtime.

In that case is it not just a case of allowing them to pass the metrics provider in the queue options?

[alvaroaleman]

In that case is it not just a case of allowing them to pass the metrics provider in the queue options?

Yeah but it still would break them by default. But yeah, making the provider public so that can be done is likely good enough.

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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-sigs/prow repository.