On Tue, Apr 28, 2015 at 1:46 AM, Steven Hardy <[email protected]> wrote:
> 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. > Just beware: https://github.com/openstack/heat/blob/master/heat/engine/resources/stack_resource.py#L328-L346 and https://review.openstack.org/#/c/173045/ This is our only current way for knowing if something has changed between 2 updates. -A > Similar problems exist for resource.Resource AFAICT. > > Steve > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
