Automatic merge from submit-queue (batch tested with PRs 47694, 47772, 47783, 47803, 47673)
Output TYPE for getting service
**What this PR does / why we need it**:
Now service already supported 4 ServiceTypes, ServiceTypes is
friendly to distinguish services, so outputing service type better
when running 'kubectl get service'.
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue (batch tested with PRs 47958, 46261, 46667, 47709, 47579)
Clean up Deployment overlap annotation code
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes#43322
**Special notes for your reviewer**:
**Release note**:
```
None
```
Automatic merge from submit-queue (batch tested with PRs 47915, 47856, 44086, 47575, 47475)
Change second StorageClass Column to provisioner
Some provisioners have key-value pairs in parameters map which key is type, here TYPE in StorageClass columns may be confused.
https://kubernetes.io/docs/concepts/storage/persistent-volumes/#storageclasses
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue (batch tested with PRs 47403, 46646, 46906, 46527, 46792)
add ContainerRuntimeVersion to `kubectl get nodes -o=wide` output
**What this PR does / why we need it**: adds container runtime version to `kubectl get nodes -o=wide` output as a way to surface more node-level information
When upgrading to a new container runtime version (docker 1.11 -> docker 1.12) or when experimenting with a different container runtime version (experimenting with rkt in a docker cluster), it's useful for cluster operators to see which nodes are running which container runtime version. `kubectl get nodes -o=wide` already provides kernel and OS version, and I believe adding container runtime version would be good.
**Release note**:
```release-note
container runtime version has been added to the output of `kubectl get nodes -o=wide` as `CONTAINER-RUNTIME`
```
Automatic merge from submit-queue (batch tested with PRs 47227, 47119, 46280, 47414, 46696)
Improve code coverage for pkg/printer
**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
hide operator when describe pod with empty value tolerations
**What this PR does / why we need it**:
The tolerations printing in `kubectl descirbe pod` is not correct when toleration.value is empty, this PR is to fix it.
Before:
```
Tolerations: node.alpha.kubernetes.io/notReady=:Exists:NoExecute for 300s
node.alpha.kubernetes.io/unreachable=:Exists:NoExecute for 300s
```
After:
```
Tolerations: node.alpha.kubernetes.io/notReady:NoExecute for 300s
node.alpha.kubernetes.io/unreachable:NoExecute for 300s
```
Also updated tests to cover all possible cases of describing pod with tolerations. See changes in of `TestDescribePodTolerations()` in `describe_test.go`
**Which issue this PR fixes**:
**Special notes for your reviewer**:
**Release note**:
```release-note
NONE
```
Now service already supported 4 ServiceTypes, ServiceTypes is
friendly to distinguish services, so outputing service type better
when running 'kubectl get service'.
Automatic merge from submit-queue
StorageOS Volume Plugin
**What this PR does / why we need it**:
This PR adds a new volume plugin for StorageOS volumes. StorageOS runs as a container on Kubelet nodes, aggregating local or attached storage and making its capacity available to all nodes within the cluster. More information at http://storageos.com.
The StorageOS plugin supports:
1. Dynamic Provisioning using Storage Classes
2. Persistent Volumes and Persistent Volume Claims.
**Which issue this PR fixes**
A feature request has been created:
https://github.com/kubernetes/features/issues/190
This isn't on the schedule for 1.6 as I wasn't sure when it would be ready. We intend to make the StorageOS container openly available within the 1.6 lifetime.
**Special notes for your reviewer**:
Separate commits for feature and godep changes.
**Release note**:
```release-note
StorageOS Volume Driver
[StorageOS](http://www.storageos.com) can be used as a storage provider for Kubernetes. With StorageOS, capacity from local or attached storage is pooled across the cluster, providing converged infrastructure for cloud-native applications.
```
Automatic merge from submit-queue (batch tested with PRs 45877, 46846, 46630, 46087, 47003)
add Unit Test for PodList Printer
Signed-off-by: zhangxiaoyu-zidif <zhang.xiaoyu33@zte.com.cn>
**What this PR does / why we need it**:
add Unit Test for PodList Printer
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue (batch tested with PRs 47024, 47050, 47086, 47081, 47013)
Wrap HumanReadablePrinter in tab output unless explicitly asked not to
`kubectl get` was not properly aligning its output due to #40848
Fixes an accidental regression. In general, we should not accept an incoming tabwriter and instead manage at a higher level. Fix the bug and add a comment re: future refactoring.
Get command now uses metadata x-kubernetes-print-columns, if present, in Openapi schema
to format output for a resource. This functionality is guarded by a boolean
flag 'use-openapi-print-columns'.
Fixes an accidental regression. In general, we should not accept an
incoming tabwriter and instead manage at a higher level. Fix the bug and
add a comment re: future refactoring.
This commit updates `kubectl describe` to display the new HPA
status conditions. This should make it easier for users to discern
the current state of the HPA.
Automatic merge from submit-queue (batch tested with PRs 46239, 46627, 46346, 46388, 46524)
move labels to components which own the APIs
During the apimachinery split in 1.6, we accidentally moved several label APIs into apimachinery. They don't belong there, since the individual APIs are not general machinery concerns, but instead are the concern of particular components: most commonly the kubelet. This pull moves the labels into their owning components and out of API machinery.
@kubernetes/sig-api-machinery-misc @kubernetes/api-reviewers @kubernetes/api-approvers
@derekwaynecarr since most of these are related to the kubelet
Automatic merge from submit-queue (batch tested with PRs 41563, 45251, 46265, 46462, 46721)
Denote if a printer is generic.
This fixes#38779.
This allows us to avoid case in which printers.GetStandardPrinter
returns nil for both printer and err removing any potential panics that
may arise throughout kubectl commands.
Please see #38779 and #38112 for complete context.
Automatic merge from submit-queue (batch tested with PRs 46432, 46701, 46326, 40848, 46396)
Add a server side Get operation
Implement proposal kubernetes/community#363
```release-note
The Kubernetes API supports retrieving tabular output for API resources via a new mime-type `application/json;as=Table;v=v1alpha1;g=meta.k8s.io`. The returned object (if the server supports it) will be of type `meta.k8s.io/v1alpha1` with `Table`, and contain column and row information related to the resource. Each row will contain information about the resource - by default it will be the object metadata, but callers can add the `?includeObject=Object` query parameter and receive the full object. In the future kubectl will use this to retrieve the results of `kubectl get`.
```
This fixes#38779.
This allows us to avoid case in which printers.GetStandardPrinter
returns nil for both printer and err removing any potential panics that
may arise throughout kubectl commands.
Please see #38779 and #38112 for complete context.
Add comment explaining adding handlers to printers.HumanReadablePrinter
also remove an unnecessary conversion of printers.HumanReadablePrinter
to printers.ResourcePrinter.
Automatic merge from submit-queue (batch tested with PRs 45488, 45335, 45909, 46074, 46615)
Add Unit Test:describe configmap
**What this PR does / why we need it**:
Add Unit Test:describe configmap
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue
add test in descibe resourcequota
**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
vSphere storage policy support for dynamic volume provisioning
Till now, vSphere cloud provider provides support to configure persistent volume with VSAN storage capabilities - kubernetes#42974. Right now this only works with VSAN.
Also there might be other use cases:
- The user might need a way to configure a policy on other datastores like VMFS, NFS etc.
- Use Storage IO control, VMCrypt policies for a persistent disk.
We can achieve about 2 use cases by using existing storage policies which are already created on vCenter using the Storage Policy Based Management service. The user will specify the SPBM policy ID as part of dynamic provisioning
- resultant persistent volume will have the policy configured with it.
- The persistent volume will be created on the compatible datastore that satisfies the storage policy requirements.
- If there are multiple compatible datastores, the datastore with the max free space would be chosen by default.
- If the user specifies the datastore along with the storage policy ID, the volume will created on this datastore if its compatible. In case if the user specified datastore is incompatible, it would error out the reasons for incompatibility to the user.
- Also, the user will be able to see the associations of persistent volume object with the policy on the vCenter once the volume is attached to the node.
For instance in the below example, the volume will created on a compatible datastore with max free space that satisfies the "Gold" storage policy requirements.
```
kind: StorageClass
apiVersion: storage.k8s.io/v1beta1
metadata:
name: fast
provisioner: kubernetes.io/vsphere-volume
parameters:
diskformat: zeroedthick
storagepolicyName: Gold
```
For instance in the below example, the vSphere CP checks if "VSANDatastore" is compatible with "Gold" storage policy requirements. If yes, volume will be provisioned on "VSANDatastore" else it will error that "VSANDatastore" is not compatible with the exact reason for failure.
```
kind: StorageClass
apiVersion: storage.k8s.io/v1beta1
metadata:
name: fast
provisioner: kubernetes.io/vsphere-volume
parameters:
diskformat: zeroedthick
storagepolicyName: Gold
datastore: VSANDatastore
```
As a part of this change, 4 commits have been added to this PR.
1. Vendor changes for vmware/govmomi
2. Changes to the VsphereVirtualDiskVolumeSource in the Kubernetes API. Added 2 additional fields StoragePolicyName, StoragePolicyID
3. Swagger and Open spec API changes.
4. vSphere Cloud Provider changes to implement the storage policy support.
**Release note**:
```release-note
vSphere cloud provider: vSphere Storage policy Support for dynamic volume provisioning
```
Automatic merge from submit-queue
LocalStorage api
**What this PR does / why we need it**:
API changes to support persistent local volumes, as described [here](https://github.com/kubernetes/community/pull/306)
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #
Part of #43640
**Special notes for your reviewer**:
There were a few items I was concerned about. Will add review comments in those places.
**Release note**:
NONE
Note will be added in subsequent PR with the volume plugin changes
Includes:
- A new volume type, LocalVolumeSource. This only supports
file-based local volumes for now.
- New alpha annotation in PV: NodeAffinity
- Validation + tests for specifying LocalVolumeSource and PV
NodeAffinity
- Alpha feature gate
Automatic merge from submit-queue (batch tested with PRs 45346, 45903, 45958, 46042, 45975)
Azure disk api
This is to update the AzureDiskApi and split it from the implementation which is caught in rebase hell...
Once this is merged, we'll get the implementation in.
@smarterclayton suggested this as a way to break the rebase hell logjam. request for a quick review.
Thanks!
Kubernetes Submit Queue