[openstack-dev] [heat] Stack/Resource updated_at conventions

Steven Hardy shardy at redhat.com
Mon Apr 27 15:46:20 UTC 2015

Hi all,

I've been looking into $subject recently, I raised this bug:


Basically we've got some historically weird and potentially inconsistent
behavior around updated_at, and I'm trying to figure out the best way to

Now, we selectively update updated_at only on the transition to
UPDATE_COMPLETE, where we store the time that we moved into
UPDATE_IN_PROGRESS.  During the update, there's no way to derive the
time we started the update.

Also, we inconsistently store the time associated with the transition into
IN_PROGRESS for suspend, resume, snapshot, restore and check actions (even
though many of these don't modify the stack definition).

The reason I need this is the hook/breakpoint API - the only way to detect
if you've hit a breakpoint is via events, and to detect you've hit a hook
during multiple sequential updates (some of which may fail or time out with
hooks pending), you need to filter the events to only consider those with a
timestamp newer than the transition of the stack to the update IN_PROGRESS.

AFAICT there's two options:

1. Update the stack.Stack so we store "now" at every transition (e.g in

2. Stop trying to explicitly control updated_at, and just allow the oslo
TimestampMixin to do it's job and update updated_at every time the DB model
is updated.

What are peoples thoughts?  Either will solve my problem, but I'm leaning
towards (2) as the cleanest and most technically correct solution.

Similar problems exist for resource.Resource AFAICT.


More information about the OpenStack-dev mailing list