Hi all, I've been looking into $subject recently, I raised this bug:
https://bugs.launchpad.net/heat/+bug/1448155 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 proceed. 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 state_set) 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. Steve __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
