<div dir="ltr">Hi!<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>-Deva<br><br><div class="gmail_quote">On Fri, Apr 3, 2015 at 1:31 AM Dmitry Tantsur <<a href="mailto:dtantsur@redhat.com">dtantsur@redhat.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all!<br>
<br>
Today I got an internal email, stating that new ironicclient brakes<br>
ironic-discoverd. Indeed, after rebase to the latest ironicclient git<br>
master, discoverd started receiving "AVAILABLE" state instead of "None"<br>
for newly enrolled nodes. It's not a valid state for introspection,<br>
valid are "MANAGEABLE" (discoverd stand-alone usage), "INSPECTING"<br>
(discoverd via Ironic driver) and None (Juno + discoverd stand-alone).<br>
Looks like despite introducing microversions we did manage to break<br>
3rdparty apps relying on states... Also we're in a bit weird situation<br>
where nodes appear ready for scheduling, despite us having a special<br>
state for managing nodes _before_ being ready for scheduling.<br>
<br>
I find the situation pretty confusing, and I'd like your comments on the<br>
following proposal to be implemented before RC1:<br>
<br>
1. add new micro-version 1.7. nodes created by API with this version<br>
will appear in state MANAGEABLE;<br>
2. make a client release with current API version set to 1.6 (thus<br>
excluding change #1 from users of this version);<br>
3. set current API version for ironicclient to 1.7 and release<br>
ironicclient version 2.0.0 to designate behavior changes;<br>
4. document the whole thingy properly<br>
<br>
#1 should be a small change, but it definitely requires FFE.<br>
Thoughts?<br>
<br>
Dmitry<br>
<br>
______________________________<u></u>______________________________<u></u>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<u></u>openstack.org?subject:<u></u>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div></div></div>