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. > > On Tue, Jun 28, 2016 at 8:28 PM, Andrew Laski > <and...@lascii.com> wrote: >> __ >> >> >> >> >> On Tue, Jun 28, 2016, at 03:26 AM, Zhenyu Zheng wrote: >>> Hi all, >>> >>> I'm working on add pagination and timestamp filter for os-instance- >>> actions API: >>> https://review.openstack.org/#/c/326326/ >>> As Alex_xu pointed out that it will be better to filter by >>> `updated_at` for timestamp filter which is reasonable, but when I >>> tried to modify the patch I found out that: >>> >>> 1. The current APIs only called _record_action_start >>> (objects.InstanceAction.action_start) and never call >>> action_finish, so >>> the field of `finish_time` is always empty in instance_actions >>> table; >> >> >> There was a spec proposed to address this, though I don't believe it >> was approved for Newton. So for now you have to assume this will >> continue to be empty. >> >> >>> >>> 2. The updated_at field is also empty, should we sync the updated_at >>> time to the created_at time when we create the action and also >>> update it whenever the action status changed, e.g finished. >> >> >> When a finish_time is recorded that should definitely also update >> updated_at. I would be in favor of having updated_at set when the >> instance action is created. I've never fully understood why Nova >> doesn't do that generally. >> >>> >>> Thanks, >>> Kevin Zheng >>> ___________________________________________________________________- >>> _________ >>> 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 >> >> >> ___________________________________________________________________- >> _______ >> 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 >> > ____________________________________________________________________- > ________ > 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
__________________________________________________________________________ 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
