✅ Deploy Preview for kubernetes-sigs-kueue ready!

Name	Link
🔨 Latest commit	2e56ce4
🔍 Latest deploy log	https://app.netlify.com/projects/kubernetes-sigs-kueue/deploys/68b83baed262d000082013d5
😎 Deploy Preview	https://deploy-preview-6715--kubernetes-sigs-kueue.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

Hi @Panlq. Thanks for your PR.

I'm waiting for a kubernetes-sigs 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.

@Panlq Thanks for reporting and proposing the fix. Since this is a bugfix it needs a release note, proposal:
/release-note-edit

Fix the validation messages when attempting to remove the queue-name label from a Deployment or StatefulSet.

/ok-to-test

/test pull-kueue-test-e2e-tas-main
infra issue

@mimowo , Hello. I have a question. For the existing inference service Deployment / StatefuleSet, if it is to be managed by kueue and upgraded again, due to this validation verification limitation, an error will be reported. Is this scenario in line with the design?

Hi I may not fully understand the question.

This change does not impact when the validation errors are reported. It only fixes the message building to report the original (old) value.

Or your question goes beyond this particular PR?

Hi I may not fully understand the question.

This change does not impact when the validation errors are reported. It only fixes the message building to report the original (old) value.

Or your question goes beyond this particular PR?

Yes, I discovered this issue while integrating an existing inference service with Kueue. The label kueue.x-k8s.io/queue-name of the existing Deployment is empty, and once integrated with Kueue, a queue-name will be injected into this label. However, based on the current update validation logic, an error is triggered. Does this scenario align with the design?

Inference services are not one-time tasks. Some of the already running ones cannot be deleted or recreated. When we need to integrate them with Kueue for quota management, we will encounter admission check failures during the subsequent service upgrade. Let’s discuss whether it is necessary to support this scenario.
@mimowo @tenzen-y

Yes, I discovered this issue while integrating an existing inference service with Kueue. The label kueue.x-k8s.io/queue-name of the existing Deployment is empty, and once integrated with Kueue, a queue-name will be injected into this label. However, based on the current update validation logic, an error is triggered.

I see, thank you for clarifying.

Does this scenario align with the design?

I don't think it is called in the design. I would say it was rather a precaution to validate against it, so I'm open to setting the label. However, we would need to test manually if this works as expected.

Let me merge this one for now, as this is clearly a bug, but I'm open to the follow up.

/lgtm
/approve
/cherrypick release-0.13
/cherrypick release-0.12

@mimowo: once the present PR merges, I will cherry-pick it on top of release-0.12, release-0.13 in new PRs and assign them to you.

LGTM label has been added.

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mimowo, Panlq

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

The pull request process is described here

/kind bug

@mimowo: new pull request created: #6716

@mimowo: new pull request created: #6717

Let me merge this one for now, as this is clearly a bug, but I'm open to the follow up.

/lgtm /approve /cherrypick release-0.13 /cherrypick release-0.12

Okay, thank you. I'll open a new discussion to address this issue. #6718