Open Stack

I'm willing to work on this, should this be a Blueprint for O?

On Sun, Jul 3, 2016 at 9:05 PM, Matt Riedemann <mriedem at linux.vnet.ibm.com>
wrote:

> 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
>
>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160704/30f578fa/attachment.html>