Automatic merge from submit-queue
Adding cascading deletion support to federated namespaces
Ref https://github.com/kubernetes/kubernetes/issues/33612
With this change, whenever a federated namespace is deleted with `DeleteOptions.OrphanDependents = false`, then federation namespace controller first deletes the corresponding namespaces from all underlying clusters before deleting the federated namespace.
cc @kubernetes/sig-cluster-federation @caesarxuchao
```release-note
Adding support for DeleteOptions.OrphanDependents for federated namespaces. Setting it to false while deleting a federated namespace also deletes the corresponding namespace from all registered clusters.
```
Automatic merge from submit-queue
Federated DaemonSet controller
Based on the secrets controller. E2e tests will come in the next PR.
**Release note**:
```release-note
Federated DaemonSet controller. Supports all the API that regular DaemonSet has.
```
cc: @quinton-hoole @kubernetes/sig-cluster-federation
Automatic merge from submit-queue
Checking function integrated with get from chanel in fed tests
Current federation controller tests assume that each actions results in only one etcd action. However, due to various timing issues, this may not necessary the truth and multiple updates can be generated. Thus tests should try to get all available messages from the debug channels instead failing on the first message, which may come from the previous test scenario.
Applied to deployment tests. Other tests will be updated in the following PR(s).
cc: @quinton-hoole @wojtek-t
Automatic merge from submit-queue
Include DaemonSets and Deployments in Namespace deletion
More generic deletion should be added next week.
cc: @quinton-hoole
Automatic merge from submit-queue
Federated deployment controller - part 1
Based on federated replicaset controller (copy + find/replace).
Remaining stuff:
- refacing out common elements to libs
- using owerref in pod analysis
- e2e tests
- renaming concurrency flag for rs and reusing it in deployment
- updating only one cluster at a time if rollingupdate strategy is used.
cc: @quinton-hoole @kubernetes/sig-cluster-federation
**Release note**:
```release-note
Federated deployment controller that supports the same api as the regular kubernetes deployment controller.
```
Automatic merge from submit-queue
Add missing argument to log message in federated ingress controller.
Minor fix, to address this:
1006 01:08:50.605184 1 ingress_controller.go:674] No annotation "kubernetes.io/ingress.global-static-ip-name" exists on ingress "e2e-tests-federated-ingress-2787b/federated-ingress" in federation, and index of cluster "federation-e2e-gce-us-central1-f" is 1 and not zero. Not queueing create operation for ingress *%!q(MISSING)* until annotation exists
Automatic merge from submit-queue
Copy objects in federation test helper
Push clean copies of passed objects in test helper in federation controllers tests.
Fixes: #33667
cc: @gmarek @quinton-hoole @kubernetes/sig-cluster-federation
Automatic merge from submit-queue
Update federation controllers to use release 1.5 clientset
This PR is based on #32243, we won't merge it until next week, to make cherry-picks easier.
Automatic merge from submit-queue
Fix goroutine leak in federation service controller
<!-- Thanks for sending a pull request! Here are some tips for you:
1. If this is your first time, read our contributor guidelines https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md and developer guide https://github.com/kubernetes/kubernetes/blob/master/docs/devel/development.md
2. If you want *faster* PR reviews, read how: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/faster_reviews.md
3. Follow the instructions for writing a release note: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/pull-requests.md#release-notes
-->
**What this PR does / why we need it**: Fixes a memory leak
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes#33186
**Special notes for your reviewer**: Every second new goroutines are created and are getting blocked waiting for the lock in the event queue. only one worker will get a lock when there are some events to process, so all the goroutines which are created every second waits for the lock forever and causes the memory/goroutine leak.
As a fix the new worker will be created only when there is no worker exist. and only one worker per cluster either waits for the event or processes all the events and goes out of existence.
```release-note
Fixes memory/goroutine leak in Federation Service controller.
```
Madhusudan.C.S