You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add a new metrics to indicates the the current queue length. #1969
Should we add a metrics named controller_runtime_queue_length to indicates the length of the queue in the controller. Some times the Reconcile has not been invoked, i want to know if the queue is emtpy.
Both repository try to set the Provider but only the earliest will take effect. In the case where component-base library is initialized first, the workqueue_depth metrics in component-base will be used and the metrics in controller-runtime will not work. It will cause the default exposed metrics in controller-runtime to be unable to show the workflow_depth number.
Is there any hint or recommendation for handling that?
@Somefive k/component-base is synced from k/k/staging/src/k8s.io/component-base and mostly for those core components of Kubernetes, such as KCM, kube-scheduler, which will not import controller-runtime.
On the other hand, most custom Operators based on controller-runtime probably don't have to rely on component-base. But if they are both imported by a project, you will find they all register to workqueue.SetProvider. So why do you need the component-base?
@Somefive k/component-base is synced from k/k/staging/src/k8s.io/component-base and mostly for those core components of Kubernetes, such as KCM, kube-scheduler, which will not import controller-runtime.
On the other hand, most custom Operators based on controller-runtime probably don't have to rely on component-base. But if they are both imported by a project, you will find they all register to workqueue.SetProvider. So why do you need the component-base?
The component-base library might not be directly depended. However, other libraries like k8s.io/apiextensions-apiserver, sigs.k8s.io/controller-runtime, github.com/coreos/prometheus-operator, and many others depends on that. If the codes in these libraries call component-base functions, the initialization function in component-base will work and might call workqueue.SetProvider before controller-runtime, which will prevent the later controller-runtime from setting its own workqueue_depth metrics.
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.
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.
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.
Activity
FillZpp commentedon Aug 9, 2022
You should use
workqueue_depth, which is the current depth of workqueue. Here are some metrics for workqueue: https://github.com/kubernetes-sigs/controller-runtime/blob/master/pkg/metrics/workqueue.go#L41Somefive commentedon Sep 30, 2022
Will there be any conflict between
controller-runtime/pkg/metrics/workqueue.go
Line 99 in 7399a3a
Both repository try to set the Provider but only the earliest will take effect. In the case where
component-baselibrary is initialized first, theworkqueue_depthmetrics incomponent-basewill be used and the metrics in controller-runtime will not work. It will cause the default exposed metrics in controller-runtime to be unable to show the workflow_depth number.Is there any hint or recommendation for handling that?
FillZpp commentedon Oct 10, 2022
@Somefive k/component-base is synced from k/k/staging/src/k8s.io/component-base and mostly for those core components of Kubernetes, such as KCM, kube-scheduler, which will not import controller-runtime.
On the other hand, most custom Operators based on controller-runtime probably don't have to rely on component-base. But if they are both imported by a project, you will find they all register to
workqueue.SetProvider. So why do you need the component-base?Somefive commentedon Oct 21, 2022
The component-base library might not be directly depended. However, other libraries like k8s.io/apiextensions-apiserver, sigs.k8s.io/controller-runtime, github.com/coreos/prometheus-operator, and many others depends on that. If the codes in these libraries call component-base functions, the initialization function in component-base will work and might call
workqueue.SetProviderbeforecontroller-runtime, which will prevent the latercontroller-runtimefrom setting its own workqueue_depth metrics.k8s-triage-robot commentedon Jan 19, 2023
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/staleis appliedlifecycle/stalewas applied,lifecycle/rottenis appliedlifecycle/rottenwas applied, the issue is closedYou can:
/remove-lifecycle stale/lifecycle rotten/closePlease send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
k8s-triage-robot commentedon Feb 18, 2023
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:
lifecycle/staleis appliedlifecycle/stalewas applied,lifecycle/rottenis appliedlifecycle/rottenwas applied, the issue is closedYou can:
/remove-lifecycle rotten/closePlease send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
k8s-triage-robot commentedon Mar 20, 2023
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:
lifecycle/staleis appliedlifecycle/stalewas applied,lifecycle/rottenis appliedlifecycle/rottenwas applied, the issue is closedYou can:
/reopen/remove-lifecycle rottenPlease send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
k8s-ci-robot commentedon Mar 20, 2023
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
Details
In response to this:
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.
RainbowMango commentedon Dec 12, 2024
/reopen
As mentioned by @Somefive, the issue indeed exists and has not yet been resolved.
k8s-ci-robot commentedon Dec 12, 2024
@RainbowMango: Reopened this issue.
Details
In response to this:
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.
k8s-triage-robot commentedon Jan 11, 2025
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:
lifecycle/staleis appliedlifecycle/stalewas applied,lifecycle/rottenis appliedlifecycle/rottenwas applied, the issue is closedYou can:
/reopen/remove-lifecycle rottenPlease send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
k8s-ci-robot commentedon Jan 11, 2025
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
Details
In response to this:
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.