Re: [openstack-dev] [Nova] Questions about instance actions' update and finish

[Zhenyu Zheng]

OK, then I will work on it in O

On Thu, Jul 7, 2016 at 12:15 AM, Matt Riedemann 
wrote:

> On 7/4/2016 1:12 AM, Zhenyu Zheng wrote:
>
>> I'm willing to work on this, should this be a Blueprint for O?
>>
>>
> The spec will need to be re-proposed for Ocata and any adjustments for the
> sorting/paging/marker discussions from this thread and/or the review should
> be laid out in the spec.
>
>
> --
>
> 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
>
__
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

Re: [openstack-dev] [Nova] Questions about instance actions' update and finish

[Matt Riedemann]

On 7/4/2016 1:12 AM, Zhenyu Zheng wrote:

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



The spec will need to be re-proposed for Ocata and any adjustments for 
the sorting/paging/marker discussions from this thread and/or the review 
should be laid out in the spec.


--

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

Re: [openstack-dev] [Nova] Questions about instance actions' update and finish

[Zhenyu Zheng]

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 
wrote:

> On 7/3/2016 6:21 AM, Alex Xu wrote:
>
>>
>>
>> 2016-07-02 2:32 GMT+08:00 Sean Dague > >:
>>
>>
>> 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-requ...@lists.openstack.org?subject:unsubscribe
>> > >
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> __
>> Ope

Re: [openstack-dev] [Nova] Questions about instance actions' update and finish

[Matt Riedemann]

On 7/3/2016 6:21 AM, Alex Xu wrote:



2016-07-02 2:32 GMT+08:00 Sean Dague mailto:s...@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-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




--

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/lis

Re: [openstack-dev] [Nova] Questions about instance actions' update and finish

[Alex Xu]

2016-07-02 2:32 GMT+08:00 Sean Dague :

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

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

Re: [openstack-dev] [Nova] Questions about instance actions' update and finish

[Matt Riedemann]

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

Re: [openstack-dev] [Nova] Questions about instance actions' update and finish

[Sean Dague]

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?

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Questions about instance actions' update and finish

[Sean Dague]

On 07/01/2016 10:37 AM, Matt Riedemann wrote:
> On 6/30/2016 11:10 AM, Chris Friesen wrote:
>>
>> For what it's worth, this is how the timestamps work for POSIX
>> filesystems. When you create a file it sets the access/modify/change
>> timestamps to the file creation time.
>>
>> Chris
>>
>> __
>>
>> 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
>>
> 
> That's a good point.

I would be +2 on setting updated == created on initial create across the
board in the system. I think people actually expect this because they
assume it's like unix time stamps, then get confused when they get None
back.

-Sean

-- 
Sean Dague
http://dague.net

__
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

Re: [openstack-dev] [Nova] Questions about instance actions' update and finish

[Matt Riedemann]

On 6/30/2016 11:10 AM, Chris Friesen wrote:


For what it's worth, this is how the timestamps work for POSIX
filesystems. When you create a file it sets the access/modify/change
timestamps to the file creation time.

Chris

__
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



That's a good point.

--

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

Re: [openstack-dev] [Nova] Questions about instance actions' update and finish

[Chris Friesen]

On 06/29/2016 09:13 PM, Edward Leafe wrote:

On Jun 29, 2016, at 10:05 PM, Matt Riedemann 
wrote:



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.


As discussed in the API meeting this morning, I thought it would be odd to
set updated_at = created_at when the record is created.


It's really very common. Think of 'updated_at' as meaning 'the last time this
record was modified'. For a new record, the initial creation is also the last
time it was modified.


For what it's worth, this is how the timestamps work for POSIX filesystems. 
When you create a file it sets the access/modify/change timestamps to the file 
creation time.


Chris

__
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

Re: [openstack-dev] [Nova] Questions about instance actions' update and finish

[Andrew Laski]

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

Re: [openstack-dev] [Nova] Questions about instance actions' update and finish

[Edward Leafe]

On Jun 29, 2016, at 10:05 PM, Matt Riedemann  wrote:
> 
>>> 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.
> 
> As discussed in the API meeting this morning, I thought it would be odd to 
> set updated_at = created_at when the record is created.

It's really very common. Think of 'updated_at' as meaning 'the last time this 
record was modified'. For a new record, the initial creation is also the last 
time it was modified.

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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

Re: [openstack-dev] [Nova] Questions about instance actions' update and finish

[Matt Riedemann]

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.

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

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.



Oh and

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


--

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

Re: [openstack-dev] [Nova] Questions about instance actions' update and finish

[Matt Riedemann]

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.


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


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.


--

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

Re: [openstack-dev] [Nova] Questions about instance actions' update and finish

[Matt Riedemann]

On 6/28/2016 7:28 AM, Andrew Laski 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.


As discussed in the API meeting this morning, I thought it would be odd 
to set updated_at = created_at when the record is created.






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




--

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

Re: [openstack-dev] [Nova] Questions about instance actions' update and finish

[Andrew Laski]

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

Re: [openstack-dev] [Nova] Questions about instance actions' update and finish

[Zhenyu Zheng]

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.

On Tue, Jun 28, 2016 at 8:28 PM, Andrew Laski  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

Re: [openstack-dev] [Nova] Questions about instance actions' update and finish

[Andrew Laski]

 
 
 
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-dev] [Nova] Questions about instance actions' update and finish

[Zhenyu Zheng]

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;

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.

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