Closed PBundyra closed 2 weeks ago
@alculquicondor @mimowo @mwielgus @tenzen-y WDYT?
If you agree with this idea I will add this to the v1beta2 wishlist.
Yeah, I never liked the mechanism, but we may want to seek additional community feedback at the batch-wg meeting / slack.
I agree with you, but let's keep it while v1beta1 for the backward compatibility.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
I agree with you, but let's keep it while v1beta1 for the backward compatibility.
Keeping for backwards compatibility makes sense, but I think we can already deprecate it, so:
Just to x-reference the related effort of promoting the VisibilityOnDemand to beta: https://github.com/kubernetes-sigs/kueue/issues/2973
@mbobrovskyi would you like to continue with this as a follow up to https://github.com/kubernetes-sigs/kueue/issues/2973?
/assign
What would you like to be cleaned: I suggest coming with a plan to deprecate the
QueueVisibility
API. I would start with deprecating theQueueVisiblity
feature gate and deleting logic behind it, and then remove the visibility field from ClusterQueue's Status when migrating to a next beta version of Kueue API.Why is this needed: There was the visibility API introduced that covers all business needs that were cover by the
QueueVisibility
API and more. The visibility API resolves all drawback related to theQueueVisibility
API and addresses its limitations. For now I don't see a rationale for maintaining theQueueVisiblity
API. Additionally I believe having two different ways (and two feature gates) to monitor pending workloads may lead to a little confusion regarding their pros and cons.