-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CLI options to follow/monitor deployments to completion #6818
Comments
I agree with this, though a CLI user might want updates even when a change hasn't occurred just to show the process isn't just hanging. I implemented this status checking without going the extra step of writing something out even if the status doesn't change and it doesn't feel right. I still think we should limit the API calls, but hide that fact behind some constant progress updates. (I believe this is also what This is my implementation: https://github.com/hashicorp/cloud-sre/blob/master/cli/lib/remote/command_watch.sh |
I've added a
|
Is this exposed via the API at all? |
Hi @Cricket007! The existing |
Is there any chance to also see the allocations? Either way: I would love to see this get released. Are there any plans for a release yet? |
Hi @tcurdt! Unfortunately we don't yet have a public roadmap for Nomad, so I can't promise you when this will land. But it's definitely something we want to do. |
I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues. |
Nomad version
Nomad 0.10.2
Issue
nomad deployment status
lacks to ability to block until a deployment is complete similar to log following/tailing or drain monitoring.nomad job run
monitors by default but not until a deployment is complete.Proposal
Add
-monitor
command tonomad deployment status
that blocks until deployment completion.nomad drain -monitor
has proven inadequate for fully understanding the drain process, so it might be a better idea to simply print the deployment'sstatus
output every time an update occurs.A stretch goal would be detecting a tty and updating the output in place vs printing new output on each update, although that would also require a flag to disable (or proper detection of piping).
Another stretch goal would be adding a
-monitor
flag tonomad job run
that would effectively switch from the currentjob run
output to the newdeployment status -monitor
output after the normaljob run
output completed.Prior art
kubectl rollout status
- https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#deployment-statusThe text was updated successfully, but these errors were encountered: