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

Angus Salkeld asalkeld at mirantis.com
Thu Nov 13 04:45:18 UTC 2014

On Sat, Nov 1, 2014 at 6:45 AM, Everett Toews <everett.toews at rackspace.com>

> 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 see have added a new section here:

Isn't that enough?


> Thanks,
> Everett
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141113/b73097c0/attachment.html>

More information about the OpenStack-dev mailing list