<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-07-02 2:32 GMT+08:00 Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="">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>
</span>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></blockquote><div><br></div><div>The marker should be a column with UniqueConstraint, the updated_at is not. But if we say the accuracy is ok, there will have problem with updated_at as None.</div><div><br></div><div>Anyway, we already freeze... probably we can begin to fix the updated_at problem first.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<span class=""><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>
</span>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></blockquote><div><br></div><div>The marker only needs to fill with the unique value. There isn't any problem order with multiple column. Some time we need order with mulitple column for stable order when the first order column is without UniqueConstraint. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<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>
<span class="im"><br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
<br>
</span><div class=""><div class="h5">__________________________________________________________________________<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></div>