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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
