Open Stack

Hi,

I want to start a different thread on this topic because I don't think this
is about whether/how to do API microversions. Rather, given that we are
going to support microversioning, how to deal with the non-backward
compatible change in 1.11 with the ENROLL state (instead of AVAILABLE)
being the provision state that a node is in, after being created/registered
in ironic.

(This was from 'Let's talk about API versions,
http://lists.openstack.org/pipermail/openstack-dev/2015-August/072287.html.)

I want to think about this before replying but others are more than welcome
to reply first so that I may not feel the need to reply :-)

--ruby
maybe chop off this and above when replying :-)

On 17 August 2015 at 20:20, Robert Collins <robertc at robertcollins.net>
wrote:

> 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
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150818/d957a551/attachment.html>