client
client copied to clipboard
knative
Add "kn service status wait" for deployment status check
Can we add a feature to kn service to check service status after deployment? This feature should be a blocking call to wait for service status to change from Unknown to final state.
This is a suggestion from a customer who is attempting to automate a GitOps workflow, but would like something like kn service wait-for-ready to be able to tell when a set of kubectl apply-ied configs have settled.
Since kn service update already supports wait-for-ready, this is simply requesting to break out that wait-for-ready.
Yes, that ~should~ shouldn't be that hard to implement (the only thing would be to also do the initial check for the status in a race-safe way)
No not yet. It's not planned for the next release (due next week), but if someone is fancy to implement this, feel free to assign it to yourself. We can then discuss the naming (which actually is the hardest problem :)
@evankanderson / @rhuss , appreciate if team can provide an update on this. Currently we are waiting for fixed amount of time before checking the status again. Can you suggest a more efficient work around while this is being worked on?
@dng00 : Lets discuss this in today's client working group call? we meet every week on Tuesday, you can find more details in the charter (today's meeting starts in about 3.5 hours from now).
I think it make sense, but I propos to call it just kn service wait and then possibly specify what to wait for as an option. Maybe make it even compliant to kubectl wait (which does something similar with kubectl only), but only if this make sense.
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.
no, not yet. It hasn't be picked up, nor is there a near-term plan from the core contributors. Any news that might impact the priority? (Still, I believe it would be a nice-to-have feature, we just don't have the spare cycles to tackle it)
I'll take it. /assign
We can have wait sub-command with --wait-timeout flag to specify timeout in number of seconds before giving up waiting for the service to become ready (default 600 seconds).
kn service wait NAME [--wait-timeout int]
kn service wait-for-ready to be able to tell when a set of kubectl apply-ied configs have settled.
Also, kn now supports kn apply with wait behaviour by default. So users can
kn service apply -f /tmp/default/ksvc/foo.yaml
Creating service 'foo' in namespace 'default':
0.025s The Route is still working to reflect the latest desired specification.
0.067s Configuration "foo" is waiting for a Revision to become ready.
5.689s ...
5.714s Ingress has not yet been reconciled.
5.762s Waiting for load balancer to be ready
5.939s Ready to serve.
Service 'foo' created to latest revision 'foo-00001' is available at URL:
http://foo.default.example.com
with this, kubectl apply -f + kn service wait can be replaced by kn service apply -f
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.
@dsimansk: GitHub didn't allow me to assign the following users: manoelmarques.
Note that only knative members with read permissions, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see the contributor guide
In response to this:
/assign @manoelmarques
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
![knative-prow[bot] avatar](https://avatars.githubusercontent.com/in/183726?v=4 "Published by a pub.dev verified publisher"){kind=small}