Apologies, forgot to add [ironic] to the subject. On 18 August 2015 at 13:27, Ruby Loo <rlooya...@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 <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
