stack updated_time isn't updated on update
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Heat |
Fix Released
|
Medium
|
Steven Hardy | ||
Kilo |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
We expose two time related metrics per stack, creation_time, and updated_time.
The updated time isn't updated on creation (perhaps understandable, but intuitively I expected it to be the same as creation time, or perhaps the last state transition during the create, e.g that from CREATE_IN_PROGRESS to CREATE_COMPLETE)
But worse than that, updated_time isn't updated when we, erm, update the stack and it goes into UPDATE_IN_PROGRESS state.
This is a problem if you care about the events since an update started, e.g because you want to monitor for hook/breakpoint events - currently this is impossible unless you derive the timestamp for the transition to UPDATE_IN_PROGRESS from another event.
It seems like we should modify updated_time every time a state transition occurs to the stack object, and probably creation_time should be the time when we persist the stack, with updated_time again registering
-bash-4.2$ heat stack-create rg100 -f resource_
+------
| id | stack_name | stack_status | creation_time |
+------
| a71bf1fc-
+------
-bash-4.2$ heat stack-show rg100 | grep _time
| creation_time | 2015-04-
| updated_time | None |
-bash-4.2$ heat stack-update rg100 -f resource_
+------
| id | stack_name | stack_status | creation_time |
+------
| a71bf1fc-
+------
-bash-4.2$ heat stack-show rg100 | grep _time
| creation_time | 2015-04-
| updated_time | None
Changed in heat: | |
assignee: | nobody → Steven Hardy (shardy) |
Changed in heat: | |
importance: | Undecided → Medium |
Changed in heat: | |
status: | In Progress → Triaged |
Changed in heat: | |
status: | Triaged → Fix Released |
So, we do some odd things, like setting the stack.Stack object updated_time on suspend/resume, but not storing it:
https:/ /github. com/openstack/ heat/blob/ master/ heat/engine/ stack.py# L1231
It seems like the most consistent behaviour would be to just update the updated_at time in state_set, so whenever the stack undergo's a state transition, we modify the updated_at timestamp.
This would enable easy selection of all events for the current operation, and the timestamp after any update COMPLETE or FAILED operation would be more accurate, since currently if an update fails we don't modify updated_at at all, only when an update completes, in which case we store the time when the update started (?!) rather than when it completed.
Similar problems seem to exist for resource update timestamps.