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


> 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