On 04/06/2015 06:53 AM, Ramakrishnan G wrote:
+1 from me. Since we don't have ENROLL state as per the state machine, I think it should be MANAGEABLE when we enroll a node. At least, it can also prevent nodes getting into a ready state even before an operator getting hands on it. One comment on #2. Before we make a new client release with v1.6, shouldn't the behaviour of the 0.x.x python-ironicclient be that, newly enroll nodes have provision_state as NOSTATE again instead of AVAILABLE ?
We no longer have NOSTATE. What people see as NOSTATE is actually AVAILABLE being mapped to None if version < 1.1. So the only way to avoid it is to default to 1.0, which will make it harder and less intuitive to access new features.
On Fri, Apr 3, 2015 at 1:59 PM, Dmitry Tantsur <dtant...@redhat.com <mailto:dtant...@redhat.com>> wrote: Hi all! Today I got an internal email, stating that new ironicclient brakes ironic-discoverd. Indeed, after rebase to the latest ironicclient git master, discoverd started receiving "AVAILABLE" state instead of "None" for newly enrolled nodes. It's not a valid state for introspection, valid are "MANAGEABLE" (discoverd stand-alone usage), "INSPECTING" (discoverd via Ironic driver) and None (Juno + discoverd stand-alone). Looks like despite introducing microversions we did manage to break 3rdparty apps relying on states... Also we're in a bit weird situation where nodes appear ready for scheduling, despite us having a special state for managing nodes _before_ being ready for scheduling. I find the situation pretty confusing, and I'd like your comments on the following proposal to be implemented before RC1: 1. add new micro-version 1.7. nodes created by API with this version will appear in state MANAGEABLE; 2. make a client release with current API version set to 1.6 (thus excluding change #1 from users of this version); 3. set current API version for ironicclient to 1.7 and release ironicclient version 2.0.0 to designate behavior changes; 4. document the whole thingy properly #1 should be a small change, but it definitely requires FFE. Thoughts? Dmitry ______________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.__openstack.org?subject:__unsubscribe <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev <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
__________________________________________________________________________ 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
