On 04/06/2015 05:15 PM, Devananda van der Veen wrote:
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.
Yeah, right.
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?
++ for waiting. If we tag it 1.0 right now, we'll have to make 2.0 in L.
And yeah, each time we pass new version of header, we'll have to
consider whether to bump major version, though I hope we won't introduce
major changes too often :)
But we do have to release 1.0.0 next cycle, it looks a bit weird that
our feature complete client has 0.x version.
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.
Stating the situation in the upgrade docs is the must IMO. While client
is in 0.x range and we're free to break it occasionally, people still
don't expect us to :) I think we also need to put information about the
header and how it affects people in ironicclient docs introduction.
-Deva
On Fri, Apr 3, 2015 at 1:31 AM Dmitry Tantsur <[email protected]
<mailto:[email protected]>> 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://[email protected]?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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
