Open Stack

+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 ?


On Fri, Apr 3, 2015 at 1:59 PM, Dmitry Tantsur <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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150406/f97f6656/attachment.html>