Open Stack

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