<div dir="ltr">I'm willing to work on this, should this be a Blueprint for O?</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 3, 2016 at 9:05 PM, Matt Riedemann <span dir="ltr"><<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 7/3/2016 6:21 AM, Alex Xu wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<br>
2016-07-02 2:32 GMT+08:00 Sean Dague <<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a><br></span>
<mailto:<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>>>:<div><div class="h5"><br>
<br>
On 06/30/2016 08:31 AM, Andrew Laski wrote:<br>
><br>
><br>
> On Wed, Jun 29, 2016, at 11:11 PM, Matt Riedemann wrote:<br>
>> On 6/29/2016 10:10 PM, Matt Riedemann wrote:<br>
>>> On 6/29/2016 6:40 AM, Andrew Laski wrote:<br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Tue, Jun 28, 2016, at 09:27 PM, Zhenyu Zheng wrote:<br>
>>>>> How about I sync updated_at and created_at in my patch, and leave the<br>
>>>>> finish to the other BP, by this way, I can use updated_at for the<br>
>>>>> timestamp filter I added and it don't need to change again once the<br>
>>>>> finish BP is complete.<br>
>>>><br>
>>>> Sounds good to me.<br>
>>>><br>
>>><br>
>>> It's been a long day so my memory might be fried, but the options we<br>
>>> talked about in the API meeting were:<br>
>>><br>
>>> 1. Setting updated_at = created_at when the instance action record is<br>
>>> created. Laski likes this, I'm not crazy about it, especially since we<br>
>>> don't do that for anything else.<br>
><br>
> I would actually like for us to do this generally. I have the same<br>
> thinking as Ed does elsewhere in this thread, the creation of a record<br>
> is an update of that record. So take my comments as applying to Nova<br>
> overall and not just this issue.<br>
<br>
Agree. Also it just simplifies a number of things. We should just start<br>
doing this going forward, and probably put some online data migrations<br>
in place next cycle to update all the old records. Once updated_at can't<br>
be null, we can handle things like this a bit better.<br>
<br>
<br>
The marker should be a column with UniqueConstraint, the updated_at is<br>
not. But if we say the accuracy is ok, there will have problem with<br>
updated_at as None.<br>
</div></div></blockquote>
<br>
Yeah I thought about this later, we don't use a timestamp field as a marker for anything else, and as noted it's not a non-nullable unique field, plus it's mutable which worries me for a marker field (created_at wouldn't change, but updated_at could).<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<br>
Anyway, we already freeze... probably we can begin to fix the updated_at<br>
problem first.<br>
<br>
<br>
>>> 2. Update the instance action's updated_at when instance action events<br>
>>> are created. I like this since the instance action is like a parent<br>
>>> resource and the event is the child, so when we create/modify an event<br>
>>> we can consider it an update to the parent. Laski thought this might be<br>
>>> weird UX given we don't expose instance action events in the REST API<br>
>>> unless you're an admin. This is also probably not something we'd do for<br>
>>> other related resources like server groups and server group members (but<br>
>>> we don't page on those either right now).<br>
><br>
> Right. My concern is just that the ordering of actions can change based<br>
> on events happening which are not visible to the user. However thinking<br>
> about it further we don't really allow multiple actions at once, except<br>
> for a few special cases like delete, so this may not end up affecting<br>
> any ordering as actions are mostly serial. I think this is a fine<br>
> solution for the issue at hand. I just think #1 is a more general<br>
> solution.<br>
><br>
>>><br>
>>> 3. Order the results by updated_at,created_at so that if updated_at<br>
>>> isn't set for older records, created_at will be used. I think we all<br>
>>> agreed in the meeting to do this regardless of #1 or #2 above.<br>
<br>
I kind of hate that as the order, because then the marker is going to<br>
have to be really funny double timestamp, right?<br>
<br>
<br>
The marker only needs to fill with the unique value. There isn't any<br>
problem order with multiple column. Some time we need order with<br>
mulitple column for stable order when the first order column is<br>
without UniqueConstraint.<br>
<br>
<br>
<br>
I guess that's the one thing I don't see in this patch is a functional<br>
test that actually loads up instance actions and iterates through<br>
demonstrating the pagination.<br>
<br>
-Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe:<br>
<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br></div></div>
<<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><span class=""><br>
<br>
<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>