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 <[email protected]
<mailto:[email protected]>> wrote:
2016-05-29 19:25 GMT-07:00 Alex Xu <[email protected]
<mailto:[email protected]>>:
>
>
> 2016-05-20 20:05 GMT+08:00 Sean Dague <[email protected]
<mailto:[email protected]>>:
>>
>> 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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
