Open Stack

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.

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

+1

> 
> Oh and
> 
> #4. Sean Dague needs to come back from leadership training camp in 
> Michigan and make these kind of API decisions for us.

+2

> 
> -- 
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev