Open Stack

To be honest, I'm tired of repeating the same arguments again and 
again... I personally would like to get something cool done, rather than 
discussing how to work around our new state machine again and again.

Now to some trolling: please include a way to users to opt-out from 
NOSTATE -> AVAILABLE renaming.

On 08/18/2015 09:11 PM, Ruby Loo wrote:
> Apologies, forgot to add [ironic] to the subject.
>
> On 18 August 2015 at 13:27, Ruby Loo <rlooyahoo at gmail.com
> <mailto:rlooyahoo at gmail.com>> wrote:
>
>     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 <mailto:robertc at robertcollins.net>> wrote:
>
>         On 11 August 2015 at 06:13, Ruby Loo <rlooyahoo at gmail.com
>         <mailto: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.

-1, it's a breaking change again. And it does not make any sense to me.

>         2) Supporting the initial state of AVAILABLE indefinitely rather
>         than
>         just until we *delete* version 1.10.

We don't delete any versions. This would be a terrible (backward 
incompatible) change, breaking the whole idea of versioning.

>         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.

That's what versioning is for, so we're fine, nothing needs to be done.

>
>         -Rob
>
>         --
>         Robert Collins <rbtcollins at hp.com <mailto: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://OpenStack-dev-request@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?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>