-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Add affinity-rules feature to configmap config-deployment #15250
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #15250 +/- ##
==========================================
+ Coverage 84.73% 84.79% +0.06%
==========================================
Files 218 218
Lines 13479 13504 +25
==========================================
+ Hits 11421 11451 +30
+ Misses 1689 1687 -2
+ Partials 369 366 -3 ☔ View full report in Codecov by Sentry. |
/retest |
@dprotaso can you take a look? Is there any other testing we may want to run before I take the WIP off from the MR? |
/retest |
/retest all |
@izabelacg: The
The following commands are available to trigger optional jobs:
Use
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. |
/test all |
/retest |
@izabelacg: The following test failed, say
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. |
/retest |
@@ -210,6 +227,10 @@ func makePodSpec(rev *v1.Revision, cfg *config.Config) (*corev1.PodSpec, error) | |||
} | |||
} | |||
|
|||
if cfg.Deployment.Affinity == deploymentconfig.PreferSpreadRevisionOverNodes && cfg.Features.PodSpecAffinity == apiconfig.Disabled { |
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.
The way I view the PodSpecAffinity
feature it's the operator letting users set the affnity themselves.
I still think if that feature is enabled and the user hasn't set the affinity then we should still use the default set by the operator.
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.
Hmm, ok. I misunderstood then. I'll take a look at the code again and adjust it accordingly
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.
Hm. IMHO, isn't the current config variation seems a bit unintuitive:
- feature: enabled = we don't set it
- feature: disabled + manually set to none = we don't set it
- feature: disabled + not manually disabled = we set it
Could we rename the flag to "defaultAffinity" and apply it, regardless of the feature config is enabled/disabled (so that is clear that we apply this by default if not specified otherwise). The user could then still enable the feature flag and override it on a service basis.
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.
Could we rename the flag to "defaultAffinity" and apply it
Changing it to defaultAffinity
makes sense - maybe defaultAffinityType
since we're not setting the affinity but the type we want.
regardless of the feature config is enabled/disabled (so that is clear that we apply this by default if not specified otherwise). The user could then still enable the feature flag and override it on a service basis.
Thats my intent and what I'm asking for.
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.
Renamed the config to defaultAffinityType
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.
Everythign looks good - one minor tweak to when we apply the defaults
# weight: 100 | ||
# ` | ||
# This may be "none" or "prefer-spread-revision-over-nodes" (default) | ||
# affinity: "prefer-spread-revision-over-nodes" |
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.
That is fine as a starting point as this is probably most folks would use. I am wondering about our defaulting strategy though, as we don't allow the user to set up as default config whatever is needed each time. For example I can imagine folks asking "required-spread-revision-over-nodes" (assuming they dont want more than one pods on the same node) or adjust the topology key (topology.kubernetes.io/zone
).
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 can imagine folks asking "required-spread-revision-over-nodes" (assuming they dont want more than one pods on the same node) or adjust the topology key (topology.kubernetes.io/zone).
We can add more types in the future and even a custom
option that allows the operator to specify a template maybe
I am wondering about our defaulting strategy though, as we don't allow the user to set up as default config whatever is needed each time.
I don't understand what do you mean?
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.
The comment is about defaulting but not with all options available upfront. Anyway we can add later for sure.
LGTM |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dprotaso, izabelacg The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
) * add affinity-rules to config-deployment configmap * run ./hack/update-codegen.sh * change affinity rules property to be a flag * run ./hack/update-codegen.sh * add default pod anti-affinity rules to PodSpec * re-arrange imports * enable pod anti affinity by default * fix value in config-deployment * fix condition for adding pod anti-affinity based on presence of a label * run ./hack/update-codegen.sh * clean up deploy tests * change property name * enable pod anti affinity by default * update deployment.yaml * adds new default for enable pod anti affinity to existing tests * change affinity type from toggle to string * run ./hack/update-codegen.sh * fix condition to apply podspec * tweak when applying the defaults * simplify condition that apply affinity defaults * rename new field to default-affinity-type * replace usage of old name affinity * rename test cases
Proposed Changes
default-affinity-type
to the config-deployment configmap that allows operators to set pod anti-affinity rules to all Knative services. The following pod anti-affinity rule get then added automatically in the deployments spec:prefer-spread-revision-over-nodes
by defaultRelease Note