[openstack-dev] [api] APIImpact flag for specs

Lucas Alvares Gomes lucasagomes at gmail.com
Thu Nov 13 09:24:27 UTC 2014


On Thu, Nov 13, 2014 at 4:45 AM, Angus Salkeld <asalkeld at mirantis.com> wrote:
> On Sat, Nov 1, 2014 at 6:45 AM, Everett Toews <everett.toews at rackspace.com>
> wrote:
>>
>> Hi All,
>>
>> Chris Yeoh started the use of an APIImpact flag in commit messages for
>> specs in Nova. It adds a requirement for an APIImpact flag in the commit
>> message for a proposed spec if it proposes changes to the REST API. This
>> will make it much easier for people such as the API Working Group who want
>> to review API changes across OpenStack to find and review proposed API
>> changes.
>>
>> For example, specifications with the APIImpact flag can be found with the
>> following query:
>>
>>
>> https://review.openstack.org/#/q/status:open+project:openstack/nova-specs+message:apiimpact,n,z
>>
>> Chris also proposed a similar change to many other projects and I did the
>> rest. Here’s the complete list if you’d like to review them.
>>
>> Barbican: https://review.openstack.org/131617
>> Ceilometer: https://review.openstack.org/131618
>> Cinder: https://review.openstack.org/131620
>> Designate: https://review.openstack.org/131621
>> Glance: https://review.openstack.org/131622
>> Heat: https://review.openstack.org/132338
>> Ironic: https://review.openstack.org/132340
>> Keystone: https://review.openstack.org/132303
>> Neutron: https://review.openstack.org/131623
>> Nova: https://review.openstack.org/#/c/129757
>> Sahara: https://review.openstack.org/132341
>> Swift: https://review.openstack.org/132342
>> Trove: https://review.openstack.org/132346
>> Zaqar: https://review.openstack.org/132348
>>
>> There are even more projects in stackforge that could use a similar
>> change. If you know of a project in stackforge that would benefit from using
>> an APIImapct flag in its specs, please propose the change and let us know
>> here.
>>
>
> I seem to have missed this, I'll place my review comment here too.
>
> I like the general idea of getting more consistent/better API. But, is
> reviewing every spec across all projects just going to introduce a new non
> scalable bottle neck into our work flow (given the increasing move away from
> this approach: moving functional tests to projects, getting projects to do
> more of their own docs, etc..). Wouldn't a better approach be to have an API
> liaison in each project that can keep track of new guidelines and catch
> potential problems?

I thought that was what we decided in the Summit. So +1, that's a great idea.

>
> I see have added a new section here:
> https://wiki.openstack.org/wiki/CrossProjectLiaisons
>
> Isn't that enough?

Seems enough, at least to start with.

Lucas

>
> Regards
> Angus
>
>>
>> Thanks,
>> Everett
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



More information about the OpenStack-dev mailing list