[openstack-dev] [nova] bp and/or spec required for new metadata service API version?
john at johngarbutt.com
Wed Jul 8 16:08:04 UTC 2015
On 6 July 2015 at 19:14, Andrew Laski <andrew at lascii.com> 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  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?
>>>  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.
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.
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
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.
More information about the OpenStack-dev