Mark all Kube feature dependencies, and require dependencies to be declared for all features #133912
Conversation
|
Skipping CI for Draft Pull Request. |
|
@pohly @johnbelamaric @LionelJouin - I assume that (and while you're here - any other DRA dependencies I should add, other than each DRA* feature depending on |
|
With DRA we had the problem that If there's now a better way to support Conceptually, all DRA* features depend on DynamicResourceAllocation. In addition, DRABindingConditions depends on DRADeviceStatus. |
5857e55 to
f85a068
Compare
|
Hmm, the AllAlpha issue came up in the sig-arch discussion, and it was suggested that it's a reasonable expectation to enable all betas when enabling all alphas. I wonder whether we should just make setting |
f85a068 to
82bbe27
Compare
We've not required that in the past, did we? I don't mind changing it, but right now we have one job which tests exactly that configuration.
That breaks if the beta feature depends on a beta API group, unless we make the same change also for |
| // depend on a less stable feature. | ||
| // | ||
| // Entries are alphabetized. | ||
| var defaultKubernetesFeatureGateDependencies = map[featuregate.Feature][]featuregate.Feature{ |
There was a problem hiding this comment.
should it be a part of a FeatureSpec? So everything is declared together
There was a problem hiding this comment.
Yeah, I would have prefered that, but that would either mean declaring the deps at each version which we don't want, or changing the package API of the versioned features (type VersionedSpecs []FeatureSpec) to have a wrapping struct, which breaks some external tooling around feature gates. We briefly discussed it in sig-arch, and decided to keep it this way for the smaller delta, and consider combining them later.
There was a problem hiding this comment.
I would vote for the need to repeat it for each version and keep it in the same collection, keeping the whole FG declaration in one place. But this opinion is not very strong.
There was a problem hiding this comment.
I think eventually we'll want to get to a single data structure (without per-version repetition), but doing it this way minimizes churn for now, and as long as unit tests verify the two are coherent, there won't be accidents
I missed this part, need to think more about this, buy my first reaction was the runtime-config aspect.. Maybe we should actually move to link featuregates and APIs ... |
|
We should think this more carefully as we can end blocking some case we are missing, we want through this with the tagging and coordination between features flags and runtimes config on the e2e and turned out to be really complex EDIT I just want to mean that this is great but it is always more difficult than we think at the beginning |
1648d74 to
843195c
Compare
|
Blocked on #134365 for integration test failures. |
843195c to
4249676
Compare
4249676 to
c23d79c
Compare
|
OK, I think this is ready for a another round of review. I broke out a few pieces, which have already merged, so this should be more manageable to review now. Let me know if you'd like me to break out the feature-specific fixes into separate PRs too. /hold cancel |
|
/skip A build change unrelated to DRA broke the DRA jobs. Please ignore for now. /test pull-kubernetes-unit |
pohly
left a comment
There was a problem hiding this comment.
I haven't looked at the full PR. The registry/resource changes look okay to me.
We wanted to expose all feature gates that a test depends in the test name, even if the test is only annotated with a single WithFeature call. I believe the necessary APIs exist in the feature gate package. I can try to follow up with a different PR which adds this.
c23d79c to
debe026
Compare
|
/retest #134632 fixed the DRA jobs. |
|
@tallclair: 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. DetailsInstructions 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. |
|
/lgtm |
|
LGTM label has been added. DetailsGit tree hash: f16e12f29db873d736146c54629c304515c5d55a |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: liggitt, tallclair The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Follow up to #133697:
Which issue(s) this PR is related to:
#133533
Does this PR introduce a user-facing change?
/sig architecture