[openstack-dev] [Ironic] Let's talk about API versions
Robert Collins
robertc at robertcollins.net
Tue Aug 18 00:20:24 UTC 2015
On 11 August 2015 at 06:13, Ruby Loo <rlooyahoo at gmail.com> wrote:
> Hi, sorry for the delay. I vote no. I understand the rationale of trying to
> do things so that we don't break our users but that's what the versioning is
> meant for and more importantly -- I think adding the ENROLL state is fairly
> important wrt the lifecycle of a node. I don't particularly want to hide
> that and/or let folks opt out of it in the long term.
>
> From a reviewer point-of-view, my concern is me trying to remember all the
> possible permutations/states etc that are possible to make sure that new
> code doesn't break existing behavior. I haven't thought out whether adding
> this new API would make that worse or not, but then, I don't really want to
> have to think about it. So KISS as much as we can! :)
I'm a little surprised by this, to be honest.
Here's why: allowing the initial state to be chosen from
ENROLL/AVAILABLE from the latest version of the API is precisely as
complex as allowing two versions of the API {old, new} where old
creates nodes in AVAILABLE and new creates nodes in ENROLL. The only
difference I can see is that eventually someday if {old} stops being
supported, then and only then we can go through the code and clean
things up.
It seems to me that the costs to us of supporting graceful transitions
for users here are:
1) A new version NEWVER of the API that supports node state being one
of {not supplied, AVAILABLE, ENROLL}, on creation, defaulting to
AVAILABLE when not supplied.
2) Supporting the initial state of AVAILABLE indefinitely rather than
just until we *delete* version 1.10.
3) CD deployments that had rolled forward to 1.11 will need to add the
state parameter to their scripts to move forward to NEWVER.
4) Don't default the client to the veresions between 1.10 and NEWVER
versions at any point.
That seems like a very small price to pay on our side, and the
benefits for users are that they can opt into the new functionality
when they are ready.
-Rob
--
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud
More information about the OpenStack-dev
mailing list