On 6 July 2015 at 19:14, Andrew Laski <[email protected]> wrote: > On 07/06/15 at 07:37pm, Sylvain Bauza wrote: >> >> Le 06/07/2015 19:22, Matt Riedemann a écrit : >>> >>> Related to this change [1] which adds a new LIBERTY openstack version to >>> the metadata service API, it's pretty trivial but it's akin to microversions >>> in the nova-api v2.1 code, and we require blueprints and specs for those >>> changes generally. >>> >>> So do we require a blueprint and optionally a spec for this type of >>> change, or is it simple enough as a bug fix on it's own? >>> >>> [1] https://review.openstack.org/#/c/197185/ > > > At the very least I think a blueprint is warranted with a discussion in the > Nova meeting. More reasoning below.
+1 I see the metadata service us a public REST API, so it needs a spec. But maybe I am looking at that the wrong way? >> IMHO, all changes to internal interfaces (not only REST APIs, including >> RPC) need a spec, in particular if the payload is changing. >> We had the same discussion for the Scheduler API where a new field was >> about to be added to the filter_properties dict. While it's pretty trivial, >> I think we need to go over all that change to see why it's needed and if >> it's backwards compatible. > > > I'm not sure I agree that all internal interface changes need a spec, but > any external interface should have one. Or at the very least have a > blueprint and a discussion on why it doesn't need a spec, just to ensure > that more than just two core reviewers are aware of the change. Anything > changing an external interface is adding new functionality and is worth a > discussion, more so than the interface change itself. +1 Lets not confuse the need for discussion and the need for a spec. We need a spec when we want a clear record of a decision and why. If a discussion drags on, and seems complicated, a spec is good to make sure we did actually all agree on the same thing. > For internal interfaces if they're in support of new functionality I think > the functionality deserves a spec, at the very least so it's documented. > But there are some changes we make that don't need a spec. Increasing the > major version of an RPC API being one example, though perhaps an exceptional > one. If a bug fix needs to update an RPC API, it seems wrong to require a spec. I know it risks breaking upgrades, but it feels a step to far. Maybe I am not looking at this correctly. The test coverage in the grenade job does reduce some of the risk, I think, even though we far from 100% coverage there. Thanks, johnthetubaguy __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
