-
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 support for topology spread constraint #12715
Add support for topology spread constraint #12715
Conversation
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). For more information, open the CLA check for this pull request. |
Welcome @stevenchen-db! It looks like this is your first PR to knative/serving 🎉 |
Hi @stevenchen-db. Thanks for your PR. I'm waiting for a knative member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
/ok-to-test |
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.
You'll want to sign the CLA - see the link above.
Also can you fill out the release note block in your PR body to say we've added this feature behind a flag
TagHeaderBasedRouting: apiConfig.Disabled, | ||
MultiContainer: apiConfig.Disabled, | ||
PodSpecAffinity: apiConfig.Disabled, | ||
PodSpecTopologySpreadConstraints: 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.
Is this change necessary? Curious what failed when you didn't have this?
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'm not sure, I was mostly going off of this as an example PR 20be262. Is it safe to not include PodSpecTopologySpreadConstraints
?
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 don't think these changes are necessary then - can you drop them
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.
Done! Also deleted the line you mentioned below
pkg/reconciler/route/table_test.go
Outdated
TagHeaderBasedRouting: cfgmap.Disabled, | ||
MultiContainer: cfgmap.Disabled, | ||
PodSpecAffinity: cfgmap.Disabled, | ||
PodSpecTopologySpreadConstraints: cfgmap.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.
same question as above
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.
same answer as above
pkg/apis/config/features_test.go
Outdated
"tag-header-based-routing": "Enabled", | ||
MultiContainer: Enabled, | ||
PodSpecAffinity: Enabled, | ||
PodSpecTopologySpreadConstraints Enabled, |
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.
Compile error - hence all the warnings/test failures
PodSpecTopologySpreadConstraints Enabled, | |
PodSpecTopologySpreadConstraints: Enabled, |
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.
thanks!
pkg/apis/config/features_test.go
Outdated
PodSpecTopologySpreadConstraints: Enabled, | ||
}), | ||
data: map[string]string{ | ||
"kubernetes.podspec-fieldtopologyspreadconstraintsref": "Enabled", |
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.
"kubernetes.podspec-fieldtopologyspreadconstraintsref": "Enabled", | |
"kubernetes.podspec-topologyspreadconstraints": "Enabled", |
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.
Since this PR is changing the PodSpec, I believe you'll need to update the schemas as well
@psschwei I didn't see other things like node affinity or container runtime in |
Since you're behind a feature flag, it doesn't. And since |
Codecov Report
@@ Coverage Diff @@
## main #12715 +/- ##
=======================================
Coverage 87.31% 87.31%
=======================================
Files 196 196
Lines 9750 9754 +4
=======================================
+ Hits 8513 8517 +4
+ Misses 952 951 -1
- Partials 285 286 +1
Continue to review full report at Codecov.
|
More a general question when changing the set of supported fields Is there a place where such changes could be collected for a future update of the spec (like with an I suggest updating https://github.com/knative/serving/blob/main/DEVELOPMENT.md?plain=1#L230-L236 in case we need to track those changed fields separately. |
@dprotaso I just tested this manually and topology spread constraints worked! Can someone trigger the e2e and formatting tests again? |
This currently goes through the Knative Trademark Committee.
Changes to the Knative spec apply to all distributions. Fields that are Kubernetes specific will probably never be accepted since K8s is really an implementation detail. And that's ok the OSS implementation can be a super set of the spec. But since the OSS distribution still values a clear separation of developer/operator concerns some fields may always stay behind a feature flag (like this one).
This field is covered by the |
I then probably don't fully understand the motivation for a spec then. I thought that one important aspect is portability between Knative installations. So, if someone uses a field that is only supported on the Kubernetes-based reference implementation, then it should be still possible to reuse the same Knative resource definition on a different implementation, which is supposed to ignore this field. So I would expect that all fields in the reference implementation are still mentioned in the spec, but with an In the 1.0 spec this might be covered via:
but a user should really know which fields can safely be used in order to keep its resources portable, so at least a list of all fields that are supported in the Kubernetes-based reference implementation but not in the spec would be very helpful for users being able to keep the Knative resources portable. |
The feature flag in this PR is off by default so I don't have any concerns about users being confused |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dprotaso, stevenchen-db 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 |
Fixes #12639.
Knative serving currently does not allow specifying
topologySpreadConstraints
in the pod spec as noted by this issueI tested this by locally building knative and applying it to a k8s cluster. Topology spread constraints were able to work after enabling them through the config-feature config map
Proposed Changes
Release Note