Open Stack

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.

>>> 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?

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