Open Stack

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 <dtantsur at redhat.com
> <mailto:dtantsur at 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 at lists.__openstack.org?subject:__unsubscribe
>     <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>