[openstack-dev] [nova] bp and/or spec required for new metadata service API version?
Andrew Laski
andrew at lascii.com
Mon Jul 6 18:14:54 UTC 2015
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.
>>
>
>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.
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.
>
>My 2cts (EUR of course)
>-Sylvain
>
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
More information about the OpenStack-dev
mailing list