Automatic merge from submit-queue (batch tested with PRs 47232, 48625, 48613, 48567, 39173)
Include leaderelection in client-go;
Fix#39117
Fix https://github.com/kubernetes/client-go/issues/28
This PR:
* includes the leaderelection to the staging client-go
* to avoid conflict with golang's testing package, renames package /testing to /testutil, and renames cache/testing to cache/testframework
```release-note
client-go now includes the leaderelection package
```
Automatic merge from submit-queue (batch tested with PRs 44412, 44810, 47130, 46017, 47829)
federation: Cleanup cluster scripts of older federation bring up method
**What this PR does / why we need it**:
Remove older method of bringing up federation via scripts. Currently `kubefed` is the only supported mechanism and is well established and stable.
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #
**Special notes for your reviewer**:
```release-note
NONE
```
Automatic merge from submit-queue (batch tested with PRs 44412, 44810, 47130, 46017, 47829)
Return clusterErr rather than err
The updateClusterIngressUIDToMasters() should return clusterErr, not err.
If the 'err' of 'masterCluster, masterUID, err := ic.getMasterCluster()' is nil and the 'clusterErr' of 'clusterObj, clusterErr := api.Scheme.DeepCopy(cluster)' is not nil, updateClusterIngressUIDToMasters() will return ("", nil).
And do not log fallbackUID when fallbackUID is nil.
Automatic merge from submit-queue
Fix some err message
**What this PR does / why we need it**:
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #
**Special notes for your reviewer**:
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue (batch tested with PRs 47619, 47951, 46260, 48277)
[Federation] Convert the deployment controller to a sync controller.
This is based off of the work done for the ReplicaSet controller. It extracts out a schedulingAdapter that handles the shared logic between the two controllers.
Targets #40989
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue (batch tested with PRs 45610, 47628)
Add Priority to Kubernetes API
**What this PR does / why we need it**: This is the first in a series of PRs to add priority to Kubernetes API. Subsequent PRs will add priority name resolution to admission controller.
**Release note**:
```release-note
Add PriorityClassName and Priority fields to PodSpec.
```
Automatic merge from submit-queue (batch tested with PRs 48012, 47443, 47702, 47178)
incluster config will be used when creating external shared informers.
**What this PR does / why we need it**:
Previously the loopback configuration was used to talk to the server.
As a consequence a custom API server was unable to talk to the root API server.
This PR changes the above by using incluster configuration to create shared informers.
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue
[Federation]Remove duplicate constants
Clean up them, the constants are defined in replicaset_test.go and replicasetcontroller_test.go, and replicaset_test.go did not use them.
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue
Add a spin-loop that waits for RBAC API's availability.
The very first thing that kubefed does when it comes up is run RBAC API discovery. We believe this sometimes fail on new clusters and as a result causes kubefed to assume that the RBAC API doesn't exist. Therefore, we are applying this workaround for now to ensure that the RBAC API is available before running kubefed.
Issue: #47737
**Release note**:
```release-note
NONE
```
/assign @csbell
/cc @dchen1107
/sig federation
The very first thing that kubefed does when it comes up is run RBAC API
discovery. We believe this sometimes fail on new clusters and as
a result causes kubefed to assume that the RBAC API doesn't exist.
Therefore, we are applying this workaround for now to ensure that the
RBAC API is available before running kubefed.
Automatic merge from submit-queue (batch tested with PRs 47851, 47824, 47858, 46099)
Revert "[Federation] Fix federated service reconcilation issue due to addition of External…"
Reverts kubernetes/kubernetes#45798
Reverting the temporary fix as the problem is fixed in #45869.
with that fix federation also can default ExternalTrafficLocalOnly if not set.
Issue: #45812
cc @MrHohn @madhusudancs @kubernetes/sig-federation-bugs
If there are 2 or more PR(s) in the queue, they will end up with
conflicts (and rechecks). So let us remove the timestamp entirely
when we generate the files.
Fixes#46814
Automatic merge from submit-queue
Fix api description
**What this PR does / why we need it**:
prefered -> preferred
the the -> the
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #
**Special notes for your reviewer**:
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue (batch tested with PRs 47451, 47410, 47598, 47616, 47473)
Revert "Ignore `daemonset-controller-hash` label key in federation before comparing the federated object with its cluster equivalent."
This reverts commit 3530c9ce87.
~This needs to wait for #47258, otherwise federation test won't pass~ (merged)
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue
Add NodeInternalIP as a fallback to federation api-server nodeport service
Previously NodeLegacyHostIP was used as a fallback (see #41243) but in 1.7 it was removed (#44830)
Now clusters where nodes have not set ExternalIP can not be used by kubefed to setup federation.
cc @shashidharatd
```release-note
kubefed will now configure NodeInternalIP as the federation API server endpoint when NodeExternalIP is unavailable for federation API servers exposed as NodePort services
```
Automatic merge from submit-queue
Made image as required in v1 Container struct.
**What this PR does / why we need it**:
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes#47244
**Special notes for your reviewer**:
**Release note**:
```release-note
none
```
Automatic merge from submit-queue (batch tested with PRs 43005, 46660, 46385, 46991, 47103)
Ignore `daemonset-controller-hash` label key in federation before comparing the federated object with its cluster equivalent.
Kubernetes daemonset controller writes a daemonset's hash to the object label as an optimization to avoid recomputing it every time. Adding a new label to the object that the federation is unaware of causes problems because federated controllers compare the objects in federation and their equivalents in clusters and try to reconcile them. This leads to a constant fight between the federated daemonset
controller and the cluster controllers, and they never reach a stable state.
Ideally, cluster components should not update an object's spec or metadata in a way federation cannot replicate. They can update an object's status though. Therefore, this daemonset hash should be a
field in daemonset's status, not a label in object meta. @janetkuo says that this label is only a short term solution. In the near future, they are going to replace it with revision numbers in daemonset status. We
can then rip this bandaid out.
Fixes#46925
**Release note**:
```release-note
NONE
```
/assign @csbell
/cc @shashidharatd @marun @nikhiljindal @perotinus
/sig federation