Bug #4352
kamaki wait has no timeout argument and shows a meaningless progress bar
| Status: | Closed | Start date: | 09/25/2013 | |
|---|---|---|---|---|
| Priority: | Medium | Due date: | 09/27/2013 | |
| Assignee: | Stavros Sachtouris | % Done: | 100% |
|
| Category: | kamaki | Spent time: | 5.00 hours | |
| Target version: | v0.11 | Estimated time: | 4.00 hours |
Description
The timeout for the kamaki wait command should be configurable via a --timeout argument.
Also, it doesn't make sense to display a progress bar which fills up slowly and changes the expected completion time.
The bar should show the total time remaining before the operation times out.
It should show a value decreasing at a constant, predictable rate.
When it becomes zero, the operation has timed out.
Also, it doesn't make sense to show completion percentage.
We're not waiting for the timeout to complete.
We're waiting for the status of a server to change, and time is running out.
Related issues
Associated revisions
Modify progress bar behavior in cyclades wait
Refs: #4352
Progress bar is now able to "count down", be "eating" the bar instead of
filling it, thus has meaning for timeouts
All waits are time-outs, except for "server BUILD"
Add a timeout argument to cli *_wait methods
Refs: #4352
History
#1 Updated by Stavros Sachtouris almost 11 years ago
- Due date set to 09/27/2013
- Priority changed from High to Medium
- Target version changed from v0.10 to v0.11
#2 Updated by Stavros Sachtouris almost 11 years ago
Currently, in case of a server_wait with 'BUILD', the status of the bar is updated w.r. to the "progress" value returned by the cyclades, thus not a timeout.
In all other cases of server_wait and other wait methods, it is a timeout. In order to modify it, the progress bar calling should be more parametrizable, or even completely replaced by a simple "count down to timeout" counter.
#3 Updated by Stavros Sachtouris almost 11 years ago
- Status changed from Assigned to Resolved
- % Done changed from 0 to 100
- Estimated time set to 4.00
#4 Updated by Stavros Sachtouris over 10 years ago
- Status changed from Resolved to Closed