Automatic merge from submit-queue (batch tested with PRs 37708, 34410)
Add restclientconfig helper fn for parsing timeout
Related downstream PR: https://github.com/openshift/origin/pull/12062 (example of use-case for this patch)
**Release note**:
```release-note
release-note-none
```
This patch adds a package `pkg/client/unversioned/clientcmd/util` and
defines a `ParseTimeout` helper function for parsing time from a
user-defined string. This allows code re-use in other packages that
require the creation of a new restclient (and therefore must set the
`--global-timeout` flag value manually).
@fabianofranz @kubernetes/cli-review
This patch adds a package `pkg/client/unversioned/clientcmd/util` and
defines a `ParseTimeout` helper function for parsing time from a
user-defined string. This allows code re-use in other packages that
require the creation of a new restclient (and therefore must set the
`--global-timeout` flag value manually).
Automatic merge from submit-queue
create service add create ExternalName service implementation
@kubernetes/kubectl create service add ExternalName support, refer #34731 for more detail.
```release-note
kubectl create service externalname
```
Automatic merge from submit-queue
When --grace-period=0 is provided, wait for deletion
The grace-period is automatically set to 1 unless --force is provided, and the client waits until the object is deleted.
This preserves backwards compatibility with 1.4 and earlier. It does not handle scenarios where the object is deleted and a new object is created with the same name because we don't have the initial object loaded (and that's a larger change for 1.5).
Fixes#37117 by relaxing the guarantees provided.
```release-note
When deleting an object with `--grace-period=0`, the client will begin a graceful deletion and wait until the resource is fully deleted. To force deletion, use the `--force` flag.
```
Automatic merge from submit-queue
Removes shorthand flag -w from kubectl apply
Fixes#37342.
A shorthand flag `-w` was introduced as flag `--prune-whitelist` for kubectl apply two weeks ago. Turned out it is not what we should do. Removing this shorthand flag before 1.5 release to prevent further issues.
@ymqytw @pwittrock
The grace-period is automatically set to 1 unless --force is provided,
and the client waits until the object is deleted.
This preserves backwards compatibility with 1.4 and earlier. It does not
handle scenarios where the object is deleted and a new object is created
with the same name.
Automatic merge from submit-queue
make kubectl create --edit iterate
`kubectl create --edit` is broken after #36148 merged.
`kubectl create --edit` will fail when a manifest that contains multiple resources.
I guess the root cause is that dynamic typer doesn't support a list of resources currently.
This PR makes `kubectl create --edit` iterate again as `kubectl create`.
Automatic merge from submit-queue
V2resource fixes
when using kubectl set resources it resets all resource fields that are not being set.
for example
$ kubectl set resources deployments nginx --limits=cpu=100m
followed by
$ kubectl set resources deployments nginx --limits=memory=256Mi
would result in the nginx deployment only limiting memory at 256Mi with the previous
limit placed on the cpu being wiped out. This behavior is corrected so that each invocation
only modifies fields set in that command and changed the testing so that the desired behavior
is checked.
Also a typo:
you must specify an update to requests or limits or (in the form of --requests/--limits)
corrected to
you must specify an update to requests or limits (in the form of --requests/--limits)
Implemented both the dry run and local flags.
Added test cases to show that both flags are operating as intended.
Removed the print statement "running in local mode" as in PR#35112
The original PR associated with these fixes where reverted due to causing a flake in hack/make-rules/test-cmd.sh, I gave the 'kubectl set resources' tests there own deployment and set the terminationGracePeriodSeconds to 0 and have run test-cmd.sh for hours without hitting the flake
Automatic merge from submit-queue
Rename PetSet to StatefulSet in docs and examples.
**What this PR does / why we need it**: Addresses some of the pre-code-freeze changes for implementing the PetSet --> StatefulSet rename. (#35534)
**Special notes for your reviewer**: This PR only changes docs and examples, as #35731 hasn't been merged yet and I don't want to create merge conflicts. I'll open another PR for any remaining code changes needed after that PR is merged. /cc @erictune @janetkuo @chrislovecnm
Automatic merge from submit-queue
Add --force to kubectl delete and explain force deletion
--force is required for --grace-period=0. --now is == --grace-period=1.
Improve command help to explain what graceful deletion is and warn about
force deletion.
Part of #34160 & #29033
```release-note
In order to bypass graceful deletion of pods (to immediately remove the pod from the API) the user must now provide the `--force` flag in addition to `--grace-period=0`. This prevents users from accidentally force deleting pods without being aware of the consequences of force deletion. Force deleting pods for resources like StatefulSets can result in multiple pods with the same name having running processes in the cluster, which may lead to data corruption or data inconsistency when using shared storage or common API endpoints.
```
Automatic merge from submit-queue
kubectl: make edit work with lists again
@kubernetes/kubectl this is fixing https://github.com/kubernetes/kubernetes/issues/20519 and slightly changes the behavior of --recursive when the directory that is being edited has files with errors. Previously since `edit` was working on an object basis, bad objects would be skipped and the editor would load the next object. We want to load multiple objects in the same list and it's impossible to load invalid objects in a list so --recursive will not work if there is any error in the directory. I think this is an acceptable trade-off.
Review here: https://github.com/kubernetes/kubernetes/pull/36148/files?w=1
Added test cases to show that both flags are operating as intended.
Removed the print statement "running in local mode" as in PR#35112
The previous attempt at the PR (PR#35050) was reverted for causeing a flake.
I believe that setting the deployments terminationGracePeriodSeconds to 0 should
take care of it. I ran hack/make-rules/test-cmd.sh 50 times in a row without encountering
the flake
--force is required for --grace-period=0. --now is == --grace-period=1.
Improve command help to explain what graceful deletion is and warn about
force deletion.
Automatic merge from submit-queue
fixed some issues with kubectl set resources
when using kubectl set resources it resets all resource fields that are not being set.
for example
# kubectl set resources deployments nginx --limits=cpu=100m
followed by
# kubectl set resources deployments nginx --limits=memory=256Mi
would result in the nginx deployment only limiting memory at 256Mi with the previous
limit placed on the cpu being wiped out. This behavior is corrected so that each invocation
only modifies fields set in that command and changed the testing so that the desired behavior
is checked.
Also a typo:
you must specify an update to requests or limits or (in the form of --requests/--limits)
corrected to
you must specify an update to requests or limits (in the form of --requests/--limits)
Implemented both the dry run and local flags.
Added test cases to show that both flags are operating as intended.
Removed the print statement "running in local mode" as in PR#35112
Automatic merge from submit-queue
Make overlapping deployments deletable
@kubernetes/deployment ptal
Fixes https://github.com/kubernetes/kubernetes/issues/34466 by 1) not adding the overlapping annotation in the working deployment, 2) updates observedGeneration for overlapping deployments, and 3) updates the kubectl deployment reaper to do non-cascading deletion for deployments with the overlapping annotation.
Automatic merge from submit-queue
support editing before creating resource
Support `kubectl create -f config.yaml --edit`
Support editing before creating resource from files, urls and stdin.
The behavior is similar to `kubectl edit`
It won't create anything when edit make no change.
partial: #18064
Based on: #33686 and #33973
```release-note
Support editing before creating resource from files, urls and stdin, e.g. `kubectl create -f config.yaml --edit`
It won't create anything when edit make no change.
```
when using kubectl set resources it resets all resource fields that are not being set.
for example
# kubectl set resources deployments nginx --limits=cpu=100m
followed by
# kubectl set resources deployments nginx --limits=memory=256Mi
would result in the nginx deployment only limiting memory at 256Mi with the previous
limit placed on the cpu being wiped out. This behavior is corrected so that each invocation
only modifies fields set in that command and changed the testing so that the desired behavior
is checked.
Also a typo:
you must specify an update to requests or limits or (in the form of --requests/--limits)
corrected to
you must specify an update to requests or limits (in the form of --requests/--limits)
changelog:
- fixed a typo in hack/make-rules/test-cmd.sh "effecting" to "affecting"
Automatic merge from submit-queue
kubectl: apply prune should fallback to basic delete when a resource has no reaper
Fixes#34790
cc @kubernetes/kubectl @MrHohn
Automatic merge from submit-queue
Add global timeout flag
**Release note**:
```release-note
Add a new global option "--request-timeout" to the `kubectl` client
```
UPSTREAM: https://github.com/kubernetes/client-go/pull/10
This patch adds a global timeout flag (viewable with `kubectl -h`) with
a default value of `0s` (meaning no timeout).
The timeout value is added to the default http client, so that zero
values and default behavior are enforced by the client.
Adding a global timeout ensures that user-made scripts won't hang for an
indefinite amount of time while performing remote calls (right now, remote
calls are re-tried up to 10 times when each attempt fails, however, there is
no option to set a timeout in order to prevent any of these 10 attempts from
hanging indefinitely).
**Example**
```
$ kubectl get pods # no timeout flag set - default to 0s (which means no
timeout)
NAME READY STATUS RESTARTS AGE
docker-registry-1-h7etw 1/1 Running 1 2h
router-1-uv0f9 1/1 Running 1 2h
$ kubectl get pods --request-timeout=0 # zero means no timeout no timeout flag set
NAME READY STATUS RESTARTS AGE
docker-registry-1-h7etw 1/1 Running 1 2h
router-1-uv0f9 1/1 Running 1 2h
$kubectl get pods --request-timeout=1ms
Unable to connect to the server: net/http: request canceled while
waiting for connection (Client.Timeout exceeded while awaiting headers)
```
Jordan Liggitt