<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 28, 2015 at 1:46 AM, Steven Hardy <span dir="ltr"><<a href="mailto:shardy@redhat.com" target="_blank">shardy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi all,<br>
<br>
I've been looking into $subject recently, I raised this bug:<br>
<br>
<a href="https://bugs.launchpad.net/heat/+bug/1448155" target="_blank">https://bugs.launchpad.net/heat/+bug/1448155</a><br>
<br>
Basically we've got some historically weird and potentially inconsistent<br>
behavior around updated_at, and I'm trying to figure out the best way to<br>
proceed.<br>
<br>
Now, we selectively update updated_at only on the transition to<br>
UPDATE_COMPLETE, where we store the time that we moved into<br>
UPDATE_IN_PROGRESS.  During the update, there's no way to derive the<br>
time we started the update.<br>
<br>
Also, we inconsistently store the time associated with the transition into<br>
IN_PROGRESS for suspend, resume, snapshot, restore and check actions (even<br>
though many of these don't modify the stack definition).<br>
<br>
The reason I need this is the hook/breakpoint API - the only way to detect<br>
if you've hit a breakpoint is via events, and to detect you've hit a hook<br>
during multiple sequential updates (some of which may fail or time out with<br>
hooks pending), you need to filter the events to only consider those with a<br>
timestamp newer than the transition of the stack to the update IN_PROGRESS.<br>
<br>
AFAICT there's two options:<br>
<br>
1. Update the stack.Stack so we store "now" at every transition (e.g in<br>
state_set)<br>
<br>
2. Stop trying to explicitly control updated_at, and just allow the oslo<br>
TimestampMixin to do it's job and update updated_at every time the DB model<br>
is updated.<br>
<br>
What are peoples thoughts?  Either will solve my problem, but I'm leaning<br>
towards (2) as the cleanest and most technically correct solution.<br></blockquote><div><br></div><div>Just beware:</div><div><a href="https://github.com/openstack/heat/blob/master/heat/engine/resources/stack_resource.py#L328-L346">https://github.com/openstack/heat/blob/master/heat/engine/resources/stack_resource.py#L328-L346</a><br></div><div>and</div><div><a href="https://review.openstack.org/#/c/173045/">https://review.openstack.org/#/c/173045/</a><br></div><div> </div><div>This is our only current way for knowing if something has changed between 2 updates.</div><div><br></div><div>-A</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Similar problems exist for resource.Resource AFAICT.<br>
<br>
Steve<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>