Open Stack

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