Add wait flags to svcat commands

[carolynvs]

A pretty common scenario is that I want to execute an operation (provision/bind) and then wait for it to be ready to use. I think it would be very dev friendly to support those with flags, instead of driving people to use bash-foo:

• svcat OP [--timeout=5m] waits for the instance to be provisioned or fail. Useful for simple scripts that aren't performing concurrent tasks. When a timeout is not set, wait some long but not infinite duration.
• svcat OP --no-wait does not wait for the operation to complete (current behavior). The status will be empty in the output. Useful when you want to chain multiple commands and wait for them later.
• svcat get RESOURCE --watch mimics the functionality of kubectl. Useful for those who didn't use --wait on the original OP or are watching an operation they didn't initiate from svcat.
• Use a slight backoff instead of polling at a set interval. We shouldn't be so aggressive on the backoff that we aren't checking status for huge spans of time. Just enough that we aren't polling every second the entire time.

• svcat provision --wait
• svcat bind --wait
• svcat deprovision --wait
• svcat unbind INSTANCE --wait waits for all bindings associated with the instance to be deleted.
• svcat unbind --name BINDING --wait
• svcat get instance NAME --wait waits until the specified instance's current operation is complete. Useful when you didn't watch on provision and want to check in later.
• svcat get binding NAME --wait, same as above but for bindings.
• svcat sync broker NAME --wait, waits for the sync to complete.
• svcat touch instance NAME --wait waits for the instance to be processed by the svc-cat controller.

Examples:

svcat provision mysql

svcat bind mysql --no-wait
svcat get binding mysql --watch

Migrated from Azure/service-catalog-cli#89

[duglin]

I would almost think it should be the opposite - make the default "wait" and add some "--no-wait" flag for the less common cases where you don't want to wait.

[carolynvs]

I agree! Not sure why I picked it to work that way when I first created that issue a while back but I'd prefer that svcat do what most people probably want by default.

I've updated the OP to switch the default behavior to waiting.

[carolynvs]

#dibs

[fejta-bot]

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]

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]

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

[mszostok]

/remove-lifecycle rotten
/lifecycle frozen

[carolynvs]

/unassign

[mrbobbytables]

This project is being archived, closing open issues and PRs.
Please see this PR for more information: kubernetes/community#6632