On 7/3/2016 6:21 AM, Alex Xu wrote:
2016-07-02 2:32 GMT+08:00 Sean Dague <[email protected]
<mailto:[email protected]>>:
On 06/30/2016 08:31 AM, Andrew Laski wrote:
>
>
> On Wed, Jun 29, 2016, at 11:11 PM, Matt Riedemann wrote:
>> On 6/29/2016 10:10 PM, Matt Riedemann wrote:
>>> On 6/29/2016 6:40 AM, Andrew Laski wrote:
>>>>
>>>>
>>>>
>>>> On Tue, Jun 28, 2016, at 09:27 PM, Zhenyu Zheng wrote:
>>>>> How about I sync updated_at and created_at in my patch, and leave the
>>>>> finish to the other BP, by this way, I can use updated_at for the
>>>>> timestamp filter I added and it don't need to change again once the
>>>>> finish BP is complete.
>>>>
>>>> Sounds good to me.
>>>>
>>>
>>> It's been a long day so my memory might be fried, but the options we
>>> talked about in the API meeting were:
>>>
>>> 1. Setting updated_at = created_at when the instance action record is
>>> created. Laski likes this, I'm not crazy about it, especially since we
>>> don't do that for anything else.
>
> I would actually like for us to do this generally. I have the same
> thinking as Ed does elsewhere in this thread, the creation of a record
> is an update of that record. So take my comments as applying to Nova
> overall and not just this issue.
Agree. Also it just simplifies a number of things. We should just start
doing this going forward, and probably put some online data migrations
in place next cycle to update all the old records. Once updated_at can't
be null, we can handle things like this a bit better.
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.
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).
Anyway, we already freeze... probably we can begin to fix the updated_at
problem first.
>>> 2. Update the instance action's updated_at when instance action events
>>> are created. I like this since the instance action is like a parent
>>> resource and the event is the child, so when we create/modify an event
>>> we can consider it an update to the parent. Laski thought this might be
>>> weird UX given we don't expose instance action events in the REST API
>>> unless you're an admin. This is also probably not something we'd do for
>>> other related resources like server groups and server group members (but
>>> we don't page on those either right now).
>
> Right. My concern is just that the ordering of actions can change based
> on events happening which are not visible to the user. However thinking
> about it further we don't really allow multiple actions at once, except
> for a few special cases like delete, so this may not end up affecting
> any ordering as actions are mostly serial. I think this is a fine
> solution for the issue at hand. I just think #1 is a more general
> solution.
>
>>>
>>> 3. Order the results by updated_at,created_at so that if updated_at
>>> isn't set for older records, created_at will be used. I think we all
>>> agreed in the meeting to do this regardless of #1 or #2 above.
I kind of hate that as the order, because then the marker is going to
have to be really funny double timestamp, right?
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.
I guess that's the one thing I don't see in this patch is a functional
test that actually loads up instance actions and iterates through
demonstrating the pagination.
-Sean
--
Sean Dague
http://dague.net
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
<http://[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
--
Thanks,
Matt Riedemann
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
