Automatic merge from submit-queue (batch tested with PRs 43505, 45168, 46439, 46677, 46623)
aggregator: unify resolver implementation and tests
This is https://github.com/kubernetes/kubernetes/pull/45082, but without the port support.
Automatic merge from submit-queue (batch tested with PRs 43505, 45168, 46439, 46677, 46623)
Add TPR to CRD migration helper.
This is a helper for migrating TPR data to CustomResource. It's rather hacky because it requires crossing apiserver boundaries, but doing it this way keeps the mess contained to the TPR code, which is scheduled for deletion anyway.
It's also not completely hands-free because making it resilient enough to be completely automated is too involved to be worth it for an alpha-to-beta migration, and would require investing significant effort to fix up soon-to-be-deleted TPR code. Instead, this feature will be documented as a best-effort helper whose results should be verified by hand.
The intended benefit of this over a totally manual process is that it should be possible to copy TPR data into a CRD without having to tear everything down in the middle. The process would look like this:
1. Upgrade to k8s 1.7. Nothing happens to your TPRs.
1. Create CRD with group/version and resource names that match the TPR. Still nothing happens to your TPRs, as the CRD is hidden by the overlapping TPR.
1. Delete the TPR. The TPR data is converted to CustomResource data, and the CRD begins serving at the same REST path.
Note that the old TPR data is left behind by this process, so watchers should not receive DELETE events. This also means the user can revert to the pre-migration state by recreating the TPR definition.
Ref. https://github.com/kubernetes/kubernetes/issues/45728
Automatic merge from submit-queue (batch tested with PRs 43505, 45168, 46439, 46677, 46623)
Test finalization for CRs
**What this PR does / why we need it**:
Updates #45511 with a test for finalizers for CRDs.
**Release note**:
```release-note
NONE
```
@deads2k
Automatic merge from submit-queue (batch tested with PRs 43505, 45168, 46439, 46677, 46623)
fix AWS tagging to add missing tags only
It seems that intention of original code was to build map of missing
tags and call AWS API to add just them, but due to typo full
set of tags was always (re)added
```release-note
NONE
```
Automatic merge from submit-queue
unit test for kubectl config set-cluster
**What this PR does / why we need it**:
unit test for create cluster
**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**:
i want test secure mode,but CA path how set?
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue
Performance tests also cover configmaps now
Similar to secrets.
We should be able to get this in once https://github.com/kubernetes/kubernetes/pull/46470 is merged.
/cc @wojtek-t @gmarek
Automatic merge from submit-queue (batch tested with PRs 46686, 45049, 46323, 45708, 46487)
[Federation][kubefed]: Use StorageClassName for etcd pvc
This PR updates kubefed to use the StorageClassName field [added in 1.6](http://blog.kubernetes.io/2017/03/dynamic-provisioning-and-storage-classes-kubernetes.html
) for etcd's pvc to allow the user to specify which storage class they want to use. If no value is provided to ``kubefed init``, the field will not be set, and initialization of the pvc may fail on a cluster without a default storage class configured.
The alpha annotation that was previously used (``volume.alpha.kubernetes.io/storage-class``) was deprecated as of 1.4 according to the following blog post:
http://blog.kubernetes.io/2016/10/dynamic-provisioning-and-storage-in-kubernetes.html
**Release note**:
```
'kubefed init' has been updated to support specification of the storage class (via --etcd-pv-storage-class) for the Persistent Volume Claim (PVC) used for etcd storage. If --etcd-pv-storage-class is not specified, the default storage class configured for the cluster will be used.
```
cc: @kubernetes/sig-federation-pr-reviews
Automatic merge from submit-queue (batch tested with PRs 46686, 45049, 46323, 45708, 46487)
Log an EBS vol's instance when attaching fails because VolumeInUse
Messages now look something like this:
E0427 15:44:37.617134 16932 attacher.go:73] Error attaching volume "vol-00095ddceae1a96ed": Error attaching EBS volume "vol-00095ddceae1a96ed" to instance "i-245203b7": VolumeInUse: vol-00095ddceae1a96ed is already attached to an instance
status code: 400, request id: f510c439-64fe-43ea-b3ef-f496a5cd0577. The volume is currently attached to instance "i-072d9328131bcd9cd"
weird that AWS doesn't bother to put that information in there for us (it does when you try to delete a vol that's in use)
```release-note
NONE
```
Automatic merge from submit-queue
Migrate kubelet to ConfigMapManager interface and use TTL-based caching manager
Fixes#41379
Sometime ago we moved to a secret manager interface for kubelet to manage secrets.
This PR's first commit moves config map management also to a similar interface.
The second commit adds TTL-based CachingConfigMapManager (similar to CachingSecretManager) and makes kubelet use it.
/cc @kubernetes/sig-node-pr-reviews @kubernetes/sig-scalability-misc @wojtek-t @dchen1107
Centralize the creation of the dialer during startup.
Have the dialer then passed in to both APIServer and Aggregator.
Aggregator the sets the dialer on its Transport base.
This should allow the SSTunnel to be used but also allow the Aggregation
Auth to work with it.
Depending on Environment InsecureSkipTLSVerify *may* need to be set to
true.
Fixed as few tests to call CreateDialer as part of start-up.
