-
Notifications
You must be signed in to change notification settings - Fork 248
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[MultiKueue] Introduce Admission Check Validation feature gate #3254
base: main
Are you sure you want to change the base?
[MultiKueue] Introduce Admission Check Validation feature gate #3254
Conversation
Skipping CI for Draft Pull Request. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: mszadkow The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
✅ Deploy Preview for kubernetes-sigs-kueue ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
/ok-to-test |
/cc |
705820a
to
219414b
Compare
…tAdmissionCheck status conditions with a feature gate. Preserve the logic without the status conditions.
219414b
to
c8c32ad
Compare
@mszadkow: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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. I understand the commands that are listed here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall this looks good.
I'm leaning to use dedicated fields in the cache for the checks so that there is a clear separation of the new and old mechanism. It will make it easier to drop the old mechanism in 0.10. Maybe it would also give us more control over the reasons, it will be better to have dedicated reasons.
// TBD: This might not be needed, but we could keep it for readability | ||
// because SingleInstanceInClusterQueue and FlavorIndependent will be false if AdmissionCheckValidationRules is off | ||
singleInstanceInClusterQueue, flavorIndependent := false, false | ||
if features.Enabled(features.AdmissionCheckValidationRules) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gating this code makes sense, but I think for reasability we can do:
newAC := AdmissionCheck{
Active
Controller
// by default SingleInstanceInClusterQueue and FlavorIndependent to false
}
if features.Enabled(features.AdmissionCheckValidationRules) {
newAC. SingleInstanceInClusterQueue =apimeta.IsStatusConditionTrue(ac.Status.Conditions, kueue.AdmissionChecksSingleInstanceInClusterQueue)
newAC.FlavorIndependent = apimeta.IsStatusConditionTrue(ac.Status.Conditions, kueue.FlavorIndependentAdmissionCheck)
}
c.admissionChecks[ac.Name] = newAC
reasons = append(reasons, kueue.ClusterQueueActiveReasonMultipleSingleInstanceControllerAdmissionChecks) | ||
for _, controller := range utilmaps.SortedKeys(c.multipleSingleInstanceControllersChecks) { | ||
messages = append(messages, fmt.Sprintf("only one AdmissionCheck of %v can be referenced for controller %q", c.multipleSingleInstanceControllersChecks[controller], controller)) | ||
if features.Enabled(features.AdmissionCheckValidationRules) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIUC we don't need any diff here if we used a dedicated cache field.
Then we can also easier drop the code in 0.10. For the hard-coded validation we can use
multipleMultiKueueChecks
and perFlavorMultiKueueChecks
@@ -333,11 +346,22 @@ func (c *clusterQueue) updateWithAdmissionChecks(checks map[string]AdmissionChec | |||
inactive = append(inactive, acName) | |||
} | |||
checksPerController[ac.Controller] = append(checksPerController[ac.Controller], acName) | |||
if ac.SingleInstanceInClusterQueue { | |||
|
|||
if features.Enabled(features.AdmissionCheckValidationRules) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similarly here, avoid the diff by using dedicated cache fields for the new checks
wantReason: "MultipleSingleInstanceControllerAdmissionChecks", | ||
wantMessage: "Can't admit new workloads: Cannot use multiple MultiKueue AdmissionChecks on the same ClusterQueue.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When the feature is disabled set reason as MultipleMultiKueueAdmissionChecks
wantReason: "FlavorIndependentAdmissionCheckAppliedPerFlavor", | ||
wantMessage: "Can't admit new workloads: MultiKueue AdmissionCheck cannot be specified per flavor.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When the gate is disabled use reason MutliKueueAdmissionCheckAppliedPerFlavor
{ | ||
Type: kueue.ClusterQueueActive, | ||
Status: metav1.ConditionFalse, | ||
Reason: "MultipleSingleInstanceControllerAdmissionChecks", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make this specific as in the other comment.
/uncc |
|
||
ginkgo.By("Disabling AdmissionCheckValidationRules feature", func() { | ||
gomega.Expect(features.SetEnable(features.AdmissionCheckValidationRules, false)).To(gomega.Succeed()) | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it should be disabled by default, no?
ginkgo.By("Enabling AdmissionCheckValidationRules feature", func() { | ||
gomega.Expect(features.SetEnable(features.AdmissionCheckValidationRules, true)).To(gomega.Succeed()) | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ginkgo.By("Enabling AdmissionCheckValidationRules feature", func() { | |
gomega.Expect(features.SetEnable(features.AdmissionCheckValidationRules, true)).To(gomega.Succeed()) | |
}) | |
ginkgo.By("Enabling AdmissionCheckValidationRules feature", func() { | |
features.SetFeatureGateDuringTest(ginkgo.GinkgoTB(), features.ConfigurableResourceTransformations, true) | |
}) |
@@ -255,6 +255,7 @@ The currently supported features are: | |||
| `TopologyAwareScheduling` | `false` | Alpha | 0.9 | | | |||
| `ConfigurableResourceTransformations` | `false` | Alpha | 0.9 | | | |||
| `WorkloadResourceRequestsSummary` | `false` | Alpha | 0.9 | | | |||
| `AdmissionCheckValidationRules` | `false` | Alpha | 0.9 | 0.9 | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| `AdmissionCheckValidationRules` | `false` | Alpha | 0.9 | 0.9 | | |
| `AdmissionCheckValidationRules` | `false` | Deprecated | 0.9 | 0.9 | |
PR needs rebase. 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. |
What type of PR is this?
/kind bug
What this PR does / why we need it:
SingleInstanceInClusterQueue
andFlavorIndependent
are confusing to the multi-cluster users.We need to wrap them with feature gate, but preserve the logic for MultiKueue Admission Checks constraints without those status conditions.
Which issue(s) this PR fixes:
Fixes #3094
Special notes for your reviewer:
Does this PR introduce a user-facing change?