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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
