Re: [openstack-dev] [nova] API changes on limit / marker / sort in Newton

2016-06-02 Thread Sean Dague 
On 06/02/2016 12:53 PM, Everett Toews wrote:
> 
>> On Jun 1, 2016, at 2:01 PM, Matt Riedemann  
>> wrote:
>>
>> Agree with Sean, I'd prefer separate microversions since it makes getting 
>> these in easier since they are easier to review (and remember we make 
>> changes to python-novaclient for each of these also).
>>
>> Also agree with using a single spec in the future, like Sean did with the 
>> API deprecation spec - deprecating multiple APIs but a single spec since the 
>> changes are the same.
> 
> I appreciate that Nova has a long and storied history around it's API. 
> Nonetheless, since it seems you're considering moving to  a new microversion, 
> we'd appreciate it if you would consider adhering to the Sorting guideline 
> [1] and helping drive consensus into the Pagination guideline [2].

Everett,

Could you be more specific as to what your complaints are? This response
is extremely vague, and mildly passive aggressive, so I don't even know
where to start on responses.

-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] API changes on limit / marker / sort in Newton

2016-06-02 Thread Everett Toews 

> On Jun 1, 2016, at 2:01 PM, Matt Riedemann  wrote:
> 
> Agree with Sean, I'd prefer separate microversions since it makes getting 
> these in easier since they are easier to review (and remember we make changes 
> to python-novaclient for each of these also).
> 
> Also agree with using a single spec in the future, like Sean did with the API 
> deprecation spec - deprecating multiple APIs but a single spec since the 
> changes are the same.

I appreciate that Nova has a long and storied history around it's API. 
Nonetheless, since it seems you're considering moving to  a new microversion, 
we'd appreciate it if you would consider adhering to the Sorting guideline [1] 
and helping drive consensus into the Pagination guideline [2].

Thanks,
Everett

[1] 
http://specs.openstack.org/openstack/api-wg/guidelines/pagination_filter_sort.html#sorting
[2] 
https://review.openstack.org/#/c/190743/21/guidelines/pagination_filter_sort.rst
__
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] API changes on limit / marker / sort in Newton

2016-06-01 Thread Matt Riedemann 

On 5/31/2016 7:38 AM, Sean Dague wrote:

On 05/30/2016 10:05 PM, Zhenyu Zheng wrote:

I think it is good to share codes and a single microversion can make
life more easier during coding.
Can we approve those specs first and then decide on the details in IRC
and patch review? Because
the non-priority spec deadline is so close.

Thanks

On Tue, May 31, 2016 at 1:09 AM, Ken'ichi Ohmichi > wrote:

2016-05-29 19:25 GMT-07:00 Alex Xu >:
>
>
> 2016-05-20 20:05 GMT+08:00 Sean Dague >:
>>
>> There are a number of changes up for spec reviews that add parameters to
>> LIST interfaces in Newton:
>>
>> * keypairs-pagination (MERGED) -
>>
>> 
https://github.com/openstack/nova-specs/blob/8d16fc11ee6d01b5a9fe1b8b7ab7fa6dff460e2a/specs/newton/approved/keypairs-pagination.rst#L2
>> * os-instances-actions - https://review.openstack.org/#/c/240401/
>> * hypervisors - https://review.openstack.org/#/c/240401/
>> * os-migrations - https://review.openstack.org/#/c/239869/
>>
>> I think that limit / marker is always a legit thing to add, and I almost
>> wish we just had a single spec which is "add limit / marker to the
>> following APIs in Newton"
>>
>
> Are you looking for code sharing or one microversion? For code sharing, it
> sounds ok if people have some co-work. Probably we need a common 
pagination
> supported model_query function for all of those. For one microversion, 
i'm a
> little hesitate, we should keep one small change, or enable all in one
> microversion. But if we have some base code for pagination support, we
> probably can make the pagination as default thing support for all list
> method?

It is nice to share some common code for this, that would be nice for
writing the api doc also to know what APIs support them.
And also nice to do it with a single microversion for the above
resources, because we can avoid microversion bumping conflict and all
of them don't seem a big change.


There is already common code for limit / marker.

I don't think these all need to be one microversion, they are honestly
easier to review if they are not.

However in future we should probably make 1 spec for all limit / marker
adds during a cycle. Just because the answer will be *yes* and seems
like more work to have everything be a dedicated spec.

-Sean



Agree with Sean, I'd prefer separate microversions since it makes 
getting these in easier since they are easier to review (and remember we 
make changes to python-novaclient for each of these also).


Also agree with using a single spec in the future, like Sean did with 
the API deprecation spec - deprecating multiple APIs but a single spec 
since the changes are the same.


--

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] API changes on limit / marker / sort in Newton

2016-05-31 Thread Sean Dague 
On 05/30/2016 10:05 PM, Zhenyu Zheng wrote:
> I think it is good to share codes and a single microversion can make
> life more easier during coding.
> Can we approve those specs first and then decide on the details in IRC
> and patch review? Because
> the non-priority spec deadline is so close.
> 
> Thanks
> 
> On Tue, May 31, 2016 at 1:09 AM, Ken'ichi Ohmichi  > wrote:
> 
> 2016-05-29 19:25 GMT-07:00 Alex Xu  >:
> >
> >
> > 2016-05-20 20:05 GMT+08:00 Sean Dague  >:
> >>
> >> There are a number of changes up for spec reviews that add parameters 
> to
> >> LIST interfaces in Newton:
> >>
> >> * keypairs-pagination (MERGED) -
> >>
> >> 
> https://github.com/openstack/nova-specs/blob/8d16fc11ee6d01b5a9fe1b8b7ab7fa6dff460e2a/specs/newton/approved/keypairs-pagination.rst#L2
> >> * os-instances-actions - https://review.openstack.org/#/c/240401/
> >> * hypervisors - https://review.openstack.org/#/c/240401/
> >> * os-migrations - https://review.openstack.org/#/c/239869/
> >>
> >> I think that limit / marker is always a legit thing to add, and I 
> almost
> >> wish we just had a single spec which is "add limit / marker to the
> >> following APIs in Newton"
> >>
> >
> > Are you looking for code sharing or one microversion? For code sharing, 
> it
> > sounds ok if people have some co-work. Probably we need a common 
> pagination
> > supported model_query function for all of those. For one microversion, 
> i'm a
> > little hesitate, we should keep one small change, or enable all in one
> > microversion. But if we have some base code for pagination support, we
> > probably can make the pagination as default thing support for all list
> > method?
> 
> It is nice to share some common code for this, that would be nice for
> writing the api doc also to know what APIs support them.
> And also nice to do it with a single microversion for the above
> resources, because we can avoid microversion bumping conflict and all
> of them don't seem a big change.

There is already common code for limit / marker.

I don't think these all need to be one microversion, they are honestly
easier to review if they are not.

However in future we should probably make 1 spec for all limit / marker
adds during a cycle. Just because the answer will be *yes* and seems
like more work to have everything be a dedicated spec.

-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] API changes on limit / marker / sort in Newton

2016-05-30 Thread Zhenyu Zheng 
I think it is good to share codes and a single microversion can make life
more easier during coding.
Can we approve those specs first and then decide on the details in IRC and
patch review? Because
the non-priority spec deadline is so close.

Thanks

On Tue, May 31, 2016 at 1:09 AM, Ken'ichi Ohmichi 
wrote:

> 2016-05-29 19:25 GMT-07:00 Alex Xu :
> >
> >
> > 2016-05-20 20:05 GMT+08:00 Sean Dague :
> >>
> >> There are a number of changes up for spec reviews that add parameters to
> >> LIST interfaces in Newton:
> >>
> >> * keypairs-pagination (MERGED) -
> >>
> >>
> https://github.com/openstack/nova-specs/blob/8d16fc11ee6d01b5a9fe1b8b7ab7fa6dff460e2a/specs/newton/approved/keypairs-pagination.rst#L2
> >> * os-instances-actions - https://review.openstack.org/#/c/240401/
> >> * hypervisors - https://review.openstack.org/#/c/240401/
> >> * os-migrations - https://review.openstack.org/#/c/239869/
> >>
> >> I think that limit / marker is always a legit thing to add, and I almost
> >> wish we just had a single spec which is "add limit / marker to the
> >> following APIs in Newton"
> >>
> >
> > Are you looking for code sharing or one microversion? For code sharing,
> it
> > sounds ok if people have some co-work. Probably we need a common
> pagination
> > supported model_query function for all of those. For one microversion,
> i'm a
> > little hesitate, we should keep one small change, or enable all in one
> > microversion. But if we have some base code for pagination support, we
> > probably can make the pagination as default thing support for all list
> > method?
>
> It is nice to share some common code for this, that would be nice for
> writing the api doc also to know what APIs support them.
> And also nice to do it with a single microversion for the above
> resources, because we can avoid microversion bumping conflict and all
> of them don't seem a big change.
>
> Thanks
>
> __
> 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] API changes on limit / marker / sort in Newton

2016-05-30 Thread Ken'ichi Ohmichi 
2016-05-29 19:25 GMT-07:00 Alex Xu :
>
>
> 2016-05-20 20:05 GMT+08:00 Sean Dague :
>>
>> There are a number of changes up for spec reviews that add parameters to
>> LIST interfaces in Newton:
>>
>> * keypairs-pagination (MERGED) -
>>
>> https://github.com/openstack/nova-specs/blob/8d16fc11ee6d01b5a9fe1b8b7ab7fa6dff460e2a/specs/newton/approved/keypairs-pagination.rst#L2
>> * os-instances-actions - https://review.openstack.org/#/c/240401/
>> * hypervisors - https://review.openstack.org/#/c/240401/
>> * os-migrations - https://review.openstack.org/#/c/239869/
>>
>> I think that limit / marker is always a legit thing to add, and I almost
>> wish we just had a single spec which is "add limit / marker to the
>> following APIs in Newton"
>>
>
> Are you looking for code sharing or one microversion? For code sharing, it
> sounds ok if people have some co-work. Probably we need a common pagination
> supported model_query function for all of those. For one microversion, i'm a
> little hesitate, we should keep one small change, or enable all in one
> microversion. But if we have some base code for pagination support, we
> probably can make the pagination as default thing support for all list
> method?

It is nice to share some common code for this, that would be nice for
writing the api doc also to know what APIs support them.
And also nice to do it with a single microversion for the above
resources, because we can avoid microversion bumping conflict and all
of them don't seem a big change.

Thanks

__
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] API changes on limit / marker / sort in Newton

2016-05-29 Thread Alex Xu 
2016-05-20 20:05 GMT+08:00 Sean Dague :

> There are a number of changes up for spec reviews that add parameters to
> LIST interfaces in Newton:
>
> * keypairs-pagination (MERGED) -
>
> https://github.com/openstack/nova-specs/blob/8d16fc11ee6d01b5a9fe1b8b7ab7fa6dff460e2a/specs/newton/approved/keypairs-pagination.rst#L2
> * os-instances-actions - https://review.openstack.org/#/c/240401/
> * hypervisors - https://review.openstack.org/#/c/240401/
> * os-migrations - https://review.openstack.org/#/c/239869/
>
> I think that limit / marker is always a legit thing to add, and I almost
> wish we just had a single spec which is "add limit / marker to the
> following APIs in Newton"
>
>
Are you looking for code sharing or one microversion? For code sharing, it
sounds ok if people have some co-work. Probably we need a common pagination
supported model_query function for all of those. For one microversion, i'm
a little hesitate, we should keep one small change, or enable all in one
microversion. But if we have some base code for pagination support, we
probably can make the pagination as default thing support for all list
method?


> Most of these came in with sort_keys as well. We currently don't have
> schema enforcement on sort_keys, so I don't think we should add any more
> instances of it until we scrub it. Right now sort_keys is mostly a way
> to generate a lot of database load because users can sort by things not
> indexed in your DB. We really should close that issue in the future, but
> I don't think we should make it any worse. I have -1s on
> os-instance-actions and hypervisors for that reason.
>
> os-instances-actions and os-migrations are time based, so they are
> proposing a changes-since. That seems logical and fine. Date seems like
> the natural sort order for those anyway, so it's "almost" limit/marker,
> except from end not the beginning. I think that in general changes-since
> on any resource which is time based should be fine, as long as that
> resource is going to natural sort by the time field in question.
>
> So... I almost feel like this should just be soft policy at this point:
>
> limit / marker - always ok
> sort_* - no more until we have a way to scrub sort (and we fix weird
> sort key issues we have)
> changes-since - ok on any resource that will natural sort with the
> updated time
>
>
> That should make proposing these kinds of additions easier for folks,
>
> -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] API changes on limit / marker / sort in Newton

2016-05-25 Thread Zhenyu Zheng 
Thanks for the information, really hope these two can get merged for Newton:
 https://review.openstack.org/#/c/240401/
 https://review.openstack.org/#/c/239869/

On Sat, May 21, 2016 at 5:55 AM, Jay Pipes  wrote:

> +1 on all your suggestions below, Sean.
>
> -jay
>
>
> On 05/20/2016 08:05 AM, Sean Dague wrote:
>
>> There are a number of changes up for spec reviews that add parameters to
>> LIST interfaces in Newton:
>>
>> * keypairs-pagination (MERGED) -
>>
>> https://github.com/openstack/nova-specs/blob/8d16fc11ee6d01b5a9fe1b8b7ab7fa6dff460e2a/specs/newton/approved/keypairs-pagination.rst#L2
>> * os-instances-actions - https://review.openstack.org/#/c/240401/
>> * hypervisors - https://review.openstack.org/#/c/240401/
>> * os-migrations - https://review.openstack.org/#/c/239869/
>>
>> I think that limit / marker is always a legit thing to add, and I almost
>> wish we just had a single spec which is "add limit / marker to the
>> following APIs in Newton"
>>
>> Most of these came in with sort_keys as well. We currently don't have
>> schema enforcement on sort_keys, so I don't think we should add any more
>> instances of it until we scrub it. Right now sort_keys is mostly a way
>> to generate a lot of database load because users can sort by things not
>> indexed in your DB. We really should close that issue in the future, but
>> I don't think we should make it any worse. I have -1s on
>> os-instance-actions and hypervisors for that reason.
>>
>> os-instances-actions and os-migrations are time based, so they are
>> proposing a changes-since. That seems logical and fine. Date seems like
>> the natural sort order for those anyway, so it's "almost" limit/marker,
>> except from end not the beginning. I think that in general changes-since
>> on any resource which is time based should be fine, as long as that
>> resource is going to natural sort by the time field in question.
>>
>> So... I almost feel like this should just be soft policy at this point:
>>
>> limit / marker - always ok
>> sort_* - no more until we have a way to scrub sort (and we fix weird
>> sort key issues we have)
>> changes-since - ok on any resource that will natural sort with the
>> updated time
>>
>>
>> That should make proposing these kinds of additions easier for folks,
>>
>> -Sean
>>
>>
> __
> 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] API changes on limit / marker / sort in Newton

2016-05-20 Thread Jay Pipes 

+1 on all your suggestions below, Sean.

-jay

On 05/20/2016 08:05 AM, Sean Dague wrote:

There are a number of changes up for spec reviews that add parameters to
LIST interfaces in Newton:

* keypairs-pagination (MERGED) -
https://github.com/openstack/nova-specs/blob/8d16fc11ee6d01b5a9fe1b8b7ab7fa6dff460e2a/specs/newton/approved/keypairs-pagination.rst#L2
* os-instances-actions - https://review.openstack.org/#/c/240401/
* hypervisors - https://review.openstack.org/#/c/240401/
* os-migrations - https://review.openstack.org/#/c/239869/

I think that limit / marker is always a legit thing to add, and I almost
wish we just had a single spec which is "add limit / marker to the
following APIs in Newton"

Most of these came in with sort_keys as well. We currently don't have
schema enforcement on sort_keys, so I don't think we should add any more
instances of it until we scrub it. Right now sort_keys is mostly a way
to generate a lot of database load because users can sort by things not
indexed in your DB. We really should close that issue in the future, but
I don't think we should make it any worse. I have -1s on
os-instance-actions and hypervisors for that reason.

os-instances-actions and os-migrations are time based, so they are
proposing a changes-since. That seems logical and fine. Date seems like
the natural sort order for those anyway, so it's "almost" limit/marker,
except from end not the beginning. I think that in general changes-since
on any resource which is time based should be fine, as long as that
resource is going to natural sort by the time field in question.

So... I almost feel like this should just be soft policy at this point:

limit / marker - always ok
sort_* - no more until we have a way to scrub sort (and we fix weird
sort key issues we have)
changes-since - ok on any resource that will natural sort with the
updated time


That should make proposing these kinds of additions easier for folks,

-Sean



__
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] API changes on limit / marker / sort in Newton

2016-05-20 Thread Sean Dague 
There are a number of changes up for spec reviews that add parameters to
LIST interfaces in Newton:

* keypairs-pagination (MERGED) -
https://github.com/openstack/nova-specs/blob/8d16fc11ee6d01b5a9fe1b8b7ab7fa6dff460e2a/specs/newton/approved/keypairs-pagination.rst#L2
* os-instances-actions - https://review.openstack.org/#/c/240401/
* hypervisors - https://review.openstack.org/#/c/240401/
* os-migrations - https://review.openstack.org/#/c/239869/

I think that limit / marker is always a legit thing to add, and I almost
wish we just had a single spec which is "add limit / marker to the
following APIs in Newton"

Most of these came in with sort_keys as well. We currently don't have
schema enforcement on sort_keys, so I don't think we should add any more
instances of it until we scrub it. Right now sort_keys is mostly a way
to generate a lot of database load because users can sort by things not
indexed in your DB. We really should close that issue in the future, but
I don't think we should make it any worse. I have -1s on
os-instance-actions and hypervisors for that reason.

os-instances-actions and os-migrations are time based, so they are
proposing a changes-since. That seems logical and fine. Date seems like
the natural sort order for those anyway, so it's "almost" limit/marker,
except from end not the beginning. I think that in general changes-since
on any resource which is time based should be fine, as long as that
resource is going to natural sort by the time field in question.

So... I almost feel like this should just be soft policy at this point:

limit / marker - always ok
sort_* - no more until we have a way to scrub sort (and we fix weird
sort key issues we have)
changes-since - ok on any resource that will natural sort with the
updated time


That should make proposing these kinds of additions easier for folks,

-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