[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)
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe

More information about the OpenStack-dev mailing list