Open Stack

On 7/1/2016 1:32 PM, Sean Dague wrote:
> 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?

Good point.

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

If we don't need to order by updated_at,created_at or update the 
instance action when a member event is created, by just setting 
created_at = updated_at for instance actions, then this is a lot simpler 
and I agree we should just do that.

-- 

Thanks,

Matt Riedemann