kcp
kcp copied to clipboard
kcp-dev
Add e2e to ensure the Kubernetes namespace controller is functional
The Kubernetes namespace controller is responsible for deleting all resources from a namespace when the namespace is deleted. Because kcp has resources in multiple logical clusters, we need to make sure the namespace controller is able to delete resources from namespaces from multiple logical clusters. It's possible we might accidentally break things in the future as we refactor & improve kcp's code, so let's make sure we have an end to end test that will catch if we break the namespace controller.
Does this imply running a subset of upstream kube's compliance e2e or would this testing be net-new?
Long-term, it probably implies carving out a subset of "generic control plane" conformance tests from upstream. But if upstream never has multiple logical clusters, I think we'll still need to create kcp variants to ensure things work in a multi-logical cluster setup. WDYT?
These cross-workspace controllers with dynamic RESTMapper are deeply broken right now. We cannot poll discovery for that. We have to come up with something else, e.g. using discovery for the native resources, and an CRD informer for the rest.
We have 60s poll interval updating a RESTMapper in a couple of places in kube-apiserver (for admission I guess) and in kube-controller-manager for GC, namespace and quota. That RESTMapper is used to iterate over all known types and its critical for consistency.
Types change by workspace (different CRDs in different workspaces). So we need a different resource list for each. Doing that with polling is not a good idea. Something that we can watch would be much better.
Issues go stale after 90d of inactivity.
After a furter 30 days, they will turn rotten.
Mark the issue as fresh with /remove-lifecycle stale.
If this issue is safe to close now please do so with /close.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
/lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
/close
@kcp-ci-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopen. Mark the issue as fresh with/remove-lifecycle rotten./close
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.