Open Stack

On Jul 27, 2016, at 1:26 PM, Hongbin Lu <hongbin.lu at huawei.com<mailto:hongbin.lu at huawei.com>> wrote:

Here is the guideline to evaluate an API change: http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html . In particular, I highlight the followings:

"""
The following types of changes are acceptable when conditionally added as a new API extension:
* Adding an optional property to a resource representation which may be supplied by clients, assuming the API previously would ignore this property.
* …
The following types of changes are generally not considered acceptable:
* A change such that a request which was successful before now results in an error response
* Changing the semantics of a property in a resource representation which may be supplied by clients.
* …
"""

Above all, as Ton mentioned, just adding a new option (--rollback) looks OK. However, the implementation should not break the existing behaviors. In particular, the proposed patch (https://review.openstack.org/#/c/343478/4/magnum/api/controllers/v1/bay.py) changes the request parameters and their types, which is considered to be unacceptable (unless bumping the microversion). To deal with that, I think there are two options:
1. Modify the proposed patch to make it backward-compatible. In particular, it should keep the existing properties as is (don’t change their types and semantics). The new option should be optional and it should be ignored if clients are sending the old requests.

Use the #1 approach above, please.

2. Keep the proposed patch as is, but bumping the microversion. You need to wait for this patch [1] to merge, and reference the microversion guide [1] to bump the version. In addition, it is highly recommended to follow the standard deprecation policy [2]. That means i) print a deprecated warning if old APIs are used, ii) document how to migrate from old APIs to new APIs, and iii) remove the old APIs after the deprecation period.

You can do this as well, but please don’t consider this an OR choice.

Adrian


[1] https://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html
[2] https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html

Best regards,
Hongbin

From: Ton Ngo [mailto:ton at us.ibm.com]
Sent: July-27-16 9:36 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Support for bay rollback may break magnum API backward compatibility


Hi Wenzhi,
Looks like you are adding the new --rollback option to bay-update. If the user does not specify this new option,
then bay-update behaves the same as before; in other words, if it fails, then the state of the bay will be left
in the partially updated mode. Is this correct? If so, this does change the API, but does not seem to break
backward compatibility.
Ton Ngo,

<image001.gif>"Wenzhi Yu (yuywz)" ---07/27/2016 04:13:07 AM---Hi folks, I am working on a patch [1] to add bay rollback machanism on update failure. But it seems

From: "Wenzhi Yu (yuywz)" <wenzhi_yu at 163.com<mailto:wenzhi_yu at 163.com>>
To: "openstack-dev" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: 07/27/2016 04:13 AM
Subject: [openstack-dev] [magnum] Support for bay rollback may break magnum API backward compatibility

________________________________



Hi folks,

I am working on a patch [1] to add bay rollback machanism on update failure. But it seems to break magnum API
backward compatibility.

I'm not sure how to deal with this, can you please give me your suggestion? Thanks!

[1]https://review.openstack.org/#/c/343478/

2016-07-27
________________________________

Best Regards,
Wenzhi Yu (yuywz)__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<mailto:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160727/fac157f8/attachment.html>