Open Stack

On 7/3/2016 6:21 AM, Alex Xu wrote:
>
>
> 2016-07-02 2:32 GMT+08:00 Sean Dague <sean at dague.net
> <mailto:sean at dague.net>>:
>
>     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.
>
>
> The marker should be a column with UniqueConstraint, the updated_at is
> not. But if we say the accuracy is ok, there will have problem with
> updated_at as None.

Yeah I thought about this later, we don't use a timestamp field as a 
marker for anything else, and as noted it's not a non-nullable unique 
field, plus it's mutable which worries me for a marker field (created_at 
wouldn't change, but updated_at could).

>
> Anyway, we already freeze... probably we can begin to fix the updated_at
> problem first.
>
>
>     >>> 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?
>
>
> The marker only needs to fill with the unique value. There isn't any
> problem order with multiple column. Some time we need order with
> mulitple column for stable order when the first order column is
> without UniqueConstraint.
>
>
>
>     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
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 

Thanks,

Matt Riedemann