Open Stack

So, as you know, I think that a breaking change like this is really bad for
our users, no matter how loudly we declare it or when we do it. Version
negotiation in the REST API doesn't give us license to do this. I also
think most users should not need to know the version number at all, should
be able to expect consistent behavior from their applications when ever
they upgrade either their server or client, and should be able to *opt in
to* changes in behavior.

An alternative to your proposal would be:
- add optional parameter to node creation REST API that accepts initial
state [ENROLL || AVAILABLE]
- default if unspecified remains AVAILABLE for backwards compatibility
- CLI grows an entirely new command "node-enroll", to enable the new
behavior
- [optional] deprecate the "node-create" command in our client over a few
release cycles


Along with the requisite API version bump to indicate the acceptance of the
new parameter, users will get the following combination of behaviors:
a) old client + new server: user app still works the same
b) new client + old server: user app still works the same
c) new client + new server: user app still works the same
d) new client + new server + user opts in to new behavior: user app must
behave differently

By contrast, your current approach will impact users in case (c) as soon as
we release a client which defaults to any API version >= 1.11.

-Deva

On Thu, Jul 16, 2015 at 4:30 AM Dmitry Tantsur <dtantsur at redhat.com> wrote:

> Hi all!
>
> Today we landed a patch [1] that switches (starting with API version
> 1.11) node creation API to default to ENROLL node state instead of
> AVAILABLE. Nothing to worry about right now: we don't default to this
> API version (yet?) in our clients. But read on to figure out how not to
> get broken in the future.
>
> Nodes in ENROLL state a basically just records in the database. They are
> not used for scheduling, the only way to make them enter the play is via
> "manage" provision actions. This means, when you switch to API 1.11 for
> node creation, your tooling will probably get broken. There are 2 steps
> to get your tooling prepared for it:
>
> 1. Switch to new version right now with fixing whatever breaks.
> If you're targetting liberty I recommend you start explicitly using 1.11
> API, e.g. for CLI:
>
>   $ ironic --ironic-api-version 1.11 node-create ....
>
> 2. Even if you're not doing step 1, you can make your code compatible
> with both pre-1.11 and 1.11 API. Just insert 2 more transitions after
> creating a node - "manage" and "provide". E.g. for CLI:
>
>   $ ironic node-set-provision-state UUID manage
>   # wait
>   $ ironic node-set-provision-state UUID provide
>   # wait
>
> For Kilo it would simply move node to MANAGEABLE and back to AVAILABLE.
>
> Important side note: some people don't realize that ALL provision state
> transitions are asynchronous. And all of them can fail! Even if "manage"
> action was seemingly instant and synchronous before 1.11, it was not.
> Now with 1.11 API in place "manage" action may take substantial time and
> may fail. Make sure your tooling account for it.
>
> Now it's up to the ironic team to decide [2] whether and when we're
> bumping ironicclient default API version to something above 1.11. Opinions?
>
> [1] https://review.openstack.org/#/c/194722/
> [2] https://review.openstack.org/#/c/196320/
>
> __________________________________________________________________________
> 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/20150720/c02649db/attachment.html>