Open Stack

Hi!

The situation you describe is the same that concerned me with regards to
stable/juno compatibility. As soon as the client library started passing a
version header by default, it exposed Kilo changes to all users. Anyone
testing from trunk would have experienced that when 99ab7777 landed.

I just tagged release 0.5.0 of python-ironicclient which includes that
change. It therefor passes X-OpenStack-Ironic-API-Version == 1.6 (this is
your #2 below). 3rd party apps that pin to < 0.5 release of
python-ironicclient will continue to get juno-esque states. I'll announce
this in a separate thread shortly.

As far as whether to default newly created nodes to AVAILABLE, MANAGEABLE,
or ENROLLED - yea, we didn't finish the state machine work this cycle - I'd
rather not introduce a change to the default state now, then change it
again in a few months, leading to further confusion.

As far as your #3, you raise a good point. Passing the version header by
default is a potentially incompatible change with prior versions of the
client. While the CLI and library API didn't change in an incompatible way,
they expose the client to new server behavior... perhaps this should be our
1.0 release of python-ironicclient? Or perhaps, since it's still in the 0.x
range, we should wait until we know the state machine work is done and
*then* tag a 1.0 release of the client?

Re: documenting this, besides release notes, emails, and changelogs - what
would you like to see? I'm happy to put the release notes for the client
into our developer docs, along with a page on upgrading from juno to kilo
that we need to write.

-Deva

On Fri, Apr 3, 2015 at 1:31 AM 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/3ff75d07/attachment.html>