Open Stack

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 <ken1ohmichi at gmail.com
>> <mailto:ken1ohmichi at gmail.com>> wrote:
>>
>>     2016-05-29 19:25 GMT-07:00 Alex Xu <soulxu at gmail.com
>>     <mailto:soulxu at gmail.com>>:
>>     >
>>     >
>>     > 2016-05-20 20:05 GMT+08:00 Sean Dague <sean at dague.net <mailto:sean at dague.net>>:
>>     >>
>>     >> 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