Automatic merge from submit-queue
kubectl/autoscale: fix tips when validating --max flag
While autoscaling, it was not clear what was the reason of failed --max flag validation.
This fix divides reasons to:
- value not provided or too low
- value of max is lower than value of min
bug 1336632
Bugzilla link: https://bugzilla.redhat.com/show_bug.cgi?id=1336632
Automatic merge from submit-queue
selector: make sure value of GT and LT is integer
GT and LT in selector has been introduced in Node Affinity feature: https://github.com/kubernetes/kubernetes/pull/19758, https://github.com/kubernetes/kubernetes/pull/18261
According to the API:
> If the operator is Gt or Lt, the values array must have a single element, which will be interpreted as an integer.
But the implementation has parsed it as float64:
ef0c9f0c5b/pkg/labels/selector.go (L183)
Modeling integer as float is dangerous. We don't even have fixed precision guarantee when doing comparison.
This PR is to get rid of this pre-optimization and convert **integer** to int64.
Automatic merge from submit-queue
Finish migration of integration tests to separate namespaces
This is also making the logs from integration tests debuggable and understandable.
Automatic merge from submit-queue
allow handler to join after the informer has started
This allows an event handler to join after a SharedInformer has started. It can't add any indexes, but it can add its reaction functions.
This works by
1. stopping the flow of events from the reflector (thus stopping updates to our store)
1. registering the new handler
1. sending synthetic "add" events to the new handler only
1. unblocking the flow of events
It would be possible to
1. block
1. list
1. add recorder
1. unblock
1. play list to as-yet unregistered handler
1. block
1. remove recorder
1. play recording
1. add new handler
1. unblock
But that is considerably more complicated. I'd rather not start there since this ought to be the exception rather than the rule.
@wojtek-t who requested this power in the initial review
@smarterclayton @liggitt I think this resolves our all-in-one ordering problem.
@hongchaodeng since this came up on the call
Automatic merge from submit-queue
dedup workqueue requeuing
Updates `workqueue.AddAfter` to only perform the add for the earliest requested requeue operation. An earlier time inserts in the earlier slot and removes the old one. A later time is ignored.
When using this conjunction with an `AddRateLimited` method, you get charged for the additional retry even though you're only queue once.
This keeps requeues from multiplying for every add.
@liggitt
Automatic merge from submit-queue
cacher: replace usable lock with conditional variable
Perviously we use a rwlock to indicate the ready information of the cacher. I feel it is not straightforward. Also it requires a few comments to explain. The pull request tries to replace the lock with a conditional variable for readability reason.
/cc @lavalamp @wojtek-t
Automatic merge from submit-queue
kubectl: ignore only update conflicts in the scaler
@kubernetes/kubectl is there any reason to retry any other errors?
* rolling.go (has all the logic for rolling deployments)
* recreate.go (has all the logic for recreate deployments)
* sync.go (has all the logic for getting and scaling replica sets)
* rollback.go (has all the logic for rolling back a deployment)
* util.go (contains all the utilities used throughout the controller)
Leave back at deployment_controller.go all the necessary bits for
creating, setting up, and running the controller loop.
Also add package documentation.
Automatic merge from submit-queue
Reorganize volume controllers and manager
* Move both PV and attach/detach volume controllers to `controllers/volume` (closes#26222)
* Rename `kubelet/volume` to `kubelet/volumemanager`
* Add/update OWNER files
Automatic merge from submit-queue
Add MinReadySeconds to rolling updater
Add MinReadySeconds support to RollingUpdater that allows to specify the number of seconds to wait on top of the pod is "ready" because its readiness probe passed.
Automatic merge from submit-queue
Use `CreatedByAnnotation` constant
A nit but didn't want the strings to get out of sync.
Signed-off-by: Doug Davis <dug@us.ibm.com>
Automatic merge from submit-queue
Add additional testing scenarios for compute resource requests=0
I was asked about the qos tier of a pod that specified
`--requests=cpu=0,memory=0 --limits=cpu=100m,memory=1Gi`
and in just investigating current behavior, realized we should have an explicit test case to ensure that 0 values are preserved in defaulting passes, and that this is still a burstable pod (but the lowest for that tier as it related to eviction)
/cc @vishh
This commit includes a proposal and a Go file to re-define the container
runtime interface.
Note that this is an experimental interface and is expected to go through
multiple revisions once developers start implementing against it. As stated in
the proposal, there are also individual issues to carry discussions of
specific features.
Automatic merge from submit-queue
Update "kubectl get all" to display resource type as part of name
fixes#23838
release-note-none
When running "kubectl get all", or printing any output with mixed resource kinds, an additional column is added to the output with each resource's kind:
`kubectl get all --all-namespaces`
```
NAMESPACE NAME DESIRED CURRENT AGE
default rc/docker-registry-1 1 1 23h
testproject rc/node-1 0 0 2d
NAMESPACE NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default svc/docker-registry 172.30.36.42 <none> 5000/TCP 23h
default svc/kubernetes 172.30.0.1 <none> 443/TCP,53/UDP,53/TCP 7d
testproject svc/ruby-ex 172.30.187.128 <none> 8080/TCP 6d
NAMESPACE NAME READY STATUS RESTARTS AGE
default po/docker-registry-1-cpf8o 1/1 Running 1 23h
```
[]()
Automatic merge from submit-queue
kubectl: don't display an empty list when trying to get a single resource that isn't found
Return immediately when attempting to get a singular resource that isn't found, so that we avoid
printing out a List if the output format is something like json or yaml.
Before:
```
$ kubectl get pod/foo -o yaml
apiVersion: v1
items: []
kind: List
metadata: {}
pods "foo" not found
```
After:
```
$ kubectl get pod/foo -o yaml
pods "foo" not found
```
Fixes#28243
@kubernetes/kubectl @kubernetes/rh-ux @smarterclayton @liggitt @deads2k @metral
Automatic merge from submit-queue
Allow specifying secret data using strings
This PR allows specifying non-binary data values in `Secret` objects as `"stringData":{"key":"string value"}`, in addition to the existing base64 []byte serializations in the `data` field.
On write, the keys and values in the `stringData` field are merged to the `data` map, overwriting any values already present in the `data` map. The move is one-way, the `stringData` field is never output when reading from the API.
A Secret could be created like this:
```
{
"kind":"Secret",
"apiVersion":"v1",
"metadata":{"name":"mysecret"},
"data":{
"image":"<base64-encoded-jpg>"
},
"stringData":{
"username": "myuser",
"password": "mypassword"
}
}
```
and when read from the API would look like this:
```
{
"kind":"Secret",
"apiVersion":"v1",
"metadata":{"name":"mysecret",...},
"data":{
"image":"<base64-encoded-jpg>"
"username": "bXl1c2Vy",
"password": "bXlwYXNzd29yZA=="
}
}
```
