| 2015-11-12 04:07:53 |
javeme |
bug |
|
|
added bug |
| 2015-11-12 04:21:43 |
OpenStack Infra |
nova: status |
New |
In Progress |
|
| 2015-11-12 04:37:55 |
javeme |
description |
Almost all of the async operations will update the task state, but the confirm_resize does not.
That would cause some trouble: our timer in the browser updates the instances based on the task state until it becomes none,
if the task state is none(any task is completed), we believe the status of an instance is stable, and there is no need to refresh the instance. But at the beginning of the confirm_resize, we did not update the task status, and the task state is still none,
so it cause we cannot know when it's completed unless we poll all of the instances of any state.
Moreover it should be at least consistent with the revert_resize,and the state RESIZE_CONFIRMING has been defined but not used. |
Almost all of the async operations would update the task state, but the confirm_resize does not.
That would cause some trouble: our timer in the browser updates the instances based on the task state until it becomes none,
if the task state is none(any task is completed), we believe the status of an instance is stable, and there is no need to refresh the instance. But at the beginning of the confirm_resize, we did not update the task status, and the task state is still none,
so it cause we cannot know when it's completed unless we poll all of the instances of any state.
Moreover it should be at least consistent with the revert_resize,and the state RESIZE_CONFIRMING has been defined but not used. |
|
| 2016-02-18 05:20:08 |
javeme |
description |
Almost all of the async operations would update the task state, but the confirm_resize does not.
That would cause some trouble: our timer in the browser updates the instances based on the task state until it becomes none,
if the task state is none(any task is completed), we believe the status of an instance is stable, and there is no need to refresh the instance. But at the beginning of the confirm_resize, we did not update the task status, and the task state is still none,
so it cause we cannot know when it's completed unless we poll all of the instances of any state.
Moreover it should be at least consistent with the revert_resize,and the state RESIZE_CONFIRMING has been defined but not used. |
Almost all of the async operations would update the task state, but the confirm_resize does not.
Not setting the task state causes problems for any applications that poll based on task state:
This would cause some trouble such as in horizon: our timer in the browser updates the instances based on the task state until it becomes none, if the task state is none(all tasks are completed), we believe the status of an instance is stable, and there is no need to refresh the instance. But at the beginning of the confirm_resize, we did not update the task status, and the task state is still none, so it cause we cannot know when it's completed unless we poll all of the instances of any state.
Moreover it should be at least consistent with the revert_resize,and the state RESIZE_CONFIRMING has been defined but not used. |
|
| 2016-02-18 05:20:40 |
javeme |
description |
Almost all of the async operations would update the task state, but the confirm_resize does not.
Not setting the task state causes problems for any applications that poll based on task state:
This would cause some trouble such as in horizon: our timer in the browser updates the instances based on the task state until it becomes none, if the task state is none(all tasks are completed), we believe the status of an instance is stable, and there is no need to refresh the instance. But at the beginning of the confirm_resize, we did not update the task status, and the task state is still none, so it cause we cannot know when it's completed unless we poll all of the instances of any state.
Moreover it should be at least consistent with the revert_resize,and the state RESIZE_CONFIRMING has been defined but not used. |
Almost all of the async operations would update the task state, but the confirm_resize does not.
Not setting the task state causes problems for any applications that poll based on task state:
This would cause some trouble in Horizon such as: our timer in the browser updates the instances based on the task state until it becomes none, if the task state is none(all tasks are completed), we believe the status of an instance is stable, and there is no need to refresh the instance. But at the beginning of the confirm_resize, we did not update the task status, and the task state is still none, so it cause we cannot know when it's completed unless we poll all of the instances of any state.
Moreover it should be at least consistent with the revert_resize,and the state RESIZE_CONFIRMING has been defined but not used. |
|
