On 4 August 2015 at 12:20, Jim Rollenhagen <j...@jimrollenhagen.com> wrote:
> On Mon, Jul 27, 2015 at 01:35:25PM -0700, Jim Rollenhagen wrote: > > > > Now we've landed a patch[0] with a new version (1.11) that is not > > backward compatible. It causes newly added Node objects to begin life in > > the ENROLL state, rather than AVAILABLE. This is a good thing, and > > people should want this! However, it is a breaking change. Automation > > that adds nodes to Ironic will need to do different things after the > > node-create call. > > > > Our API versioning scheme makes this opt-in (by specifying the API > > version). However, some folks have a problem with releasing this change > > as-is. The logic is that we might release a client that defaults to 1.11 > > or higher, or the user may request 1.12 later to get a new feature, thus > > breaking their application that enrolls nodes. > > So after much deliberation, we took an informal vote in IRC this morning > between 5 out of our 9 cores. > > The question was: "should we do a 1.12 api version that allows the user > to pick begining provision state in (AVAILABLE, ENROLL), defaulting to > AVAILABLE?" > > The results were 3 for no, 2 for yes. So that's the plan. > > Other Ironic cores (Haomeng, Yuriy, Ramesh, Ruby): please chime in if > you have opinions on this. :) > > Otherwise we'll be getting to work on releasing a server as-is in the > next few days. > > // jim > > 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! :) --ruby
__________________________________________________________________________ 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