kubernetes / kubectl

Issue tracker and mirror of kubectl code
Apache License 2.0
2.84k stars 917 forks source link

wait command can be more robust #665

Open ptone opened 5 years ago

ptone commented 5 years ago

A use of the wait command is useful in sequential automated deployment of kube resources.

However the command is currently rather brittle in automation as if the resources are not yet created, wait simply exists with an error

for example in a snippet like this:

kubectl create -f ceph/common.yaml
kubectl create -f ceph/operator.yaml
kubectl wait --for=condition=Ready pod \
-l "app=rook-ceph-operator" \
-l "app=rook-ceph-agent" \
-l "app=rook-discover" \
-n rook-ceph \
--timeout 2m

The wait command errors out, as pods matching those labels are still being created. This means for automation, there needs to be some other "pre-wait" step - which if it is in the form of bash until loop, might was well just do the job of wait.

I'd propose that kubectl wait absorb doesNotExist style errors within the timeout period, but emit them at timeout.

pswica commented 5 years ago

I tried testing this and I don't think I'm seeing the failure that you are:

kubectl apply -f pg.yaml && kubectl wait --for=condition=Ready pod -l app="postgres" --timeout 2m

Output (after waiting at a blank prompt for 20 or so seconds to download the postgres docker container for the first time and run it):

deployment.apps/postgres created
pod/postgres-86cb4984cf-bhnbh condition met

What error message did you get?

fejta-bot commented 5 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

seans3 commented 5 years ago

/sig cli /area kubectl /kind bug

/remove-lifecycle stale

fejta-bot commented 4 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

seans3 commented 4 years ago

/remove-lifecycle stale

fejta-bot commented 4 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

fejta-bot commented 4 years ago

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten

seans3 commented 4 years ago

/remove-lifecycle rotten

soltysh commented 4 years ago

This is definitely a valid issue, kubectl wait is still young command. From quick look at code the problem seems to be with this line https://github.com/kubernetes/kubernetes/blob/8dd93ca94c253c161e9affcd22ffa0e25c8e683d/staging/src/k8s.io/kubectl/pkg/cmd/wait/wait.go#L230 which re-uses ResourceFinder, we most probably need to support some kind of wait for create, similarly how we wait for other conditions.

seans3 commented 4 years ago

/remove-kind bug /kind feature

eddiezane commented 4 years ago

/priority backlog

fejta-bot commented 3 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

fejta-bot commented 3 years ago

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten

soltysh commented 3 years ago

/remove-lifecycle rotten /lifecycle frozen

brianpursley commented 3 years ago

we most probably need to support some kind of wait for create, similarly how we wait for other conditions.

@soltysh are you thinking this would be a new —for=create option that works similar to how it waits for deletion, but instead waits for the resource to exist (without consideration for its status)?