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 <robe...@robertcollins.net> wrote: > On 11 August 2015 at 06:13, Ruby Loo <rlooya...@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 <rbtcoll...@hp.com> > Distinguished Technologist > HP Converged Cloud > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev