Thanks for giving me a chance to vote. I don't have any experience talking to production/live Ironic using a client and only talk to my own devstack. Personally I vote for a *no* (for such a 1.12) the reasons that have been cited in the previous threads that
1) we need users to be aware of API versions (so I also would want them to pin it if they wanted a stable one, so don't default in their automation and keep testing and updating to the newer api versions) 2) it's already released, and i also tend to consider anything released could already being used right now On Tue, Aug 4, 2015 at 9:50 PM, 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 > > __________________________________________________________________________ > 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