<div dir="ltr">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.<div><br></div><div>An alternative to your proposal would be:</div><div>- add optional parameter to node creation REST API that accepts initial state [ENROLL || AVAILABLE]</div><div>- default if unspecified remains AVAILABLE for backwards compatibility</div><div>- CLI grows an entirely new command "node-enroll", to enable the new behavior</div><div>- [optional] deprecate the "node-create" command in our client over a few release cycles</div><div><br></div><div><br></div><div>Along with the requisite API version bump to indicate the acceptance of the new parameter, users will get the following combination of behaviors:</div><div>a) old client + new server: user app still works the same</div><div>b) new client + old server: user app still works the same</div><div>c) new client + new server: user app still works the same</div><div>d) new client + new server + user opts in to new behavior: user app must behave differently</div><div><br></div><div>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.</div><div><br></div><div>-Deva</div><div><br></div><div><div class="gmail_quote"><div dir="ltr">On Thu, Jul 16, 2015 at 4:30 AM Dmitry Tantsur <<a href="mailto:dtantsur@redhat.com">dtantsur@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all!<br>
<br>
Today we landed a patch [1] that switches (starting with API version<br>
1.11) node creation API to default to ENROLL node state instead of<br>
AVAILABLE. Nothing to worry about right now: we don't default to this<br>
API version (yet?) in our clients. But read on to figure out how not to<br>
get broken in the future.<br>
<br>
Nodes in ENROLL state a basically just records in the database. They are<br>
not used for scheduling, the only way to make them enter the play is via<br>
"manage" provision actions. This means, when you switch to API 1.11 for<br>
node creation, your tooling will probably get broken. There are 2 steps<br>
to get your tooling prepared for it:<br>
<br>
1. Switch to new version right now with fixing whatever breaks.<br>
If you're targetting liberty I recommend you start explicitly using 1.11<br>
API, e.g. for CLI:<br>
<br>
  $ ironic --ironic-api-version 1.11 node-create ....<br>
<br>
2. Even if you're not doing step 1, you can make your code compatible<br>
with both pre-1.11 and 1.11 API. Just insert 2 more transitions after<br>
creating a node - "manage" and "provide". E.g. for CLI:<br>
<br>
  $ ironic node-set-provision-state UUID manage<br>
  # wait<br>
  $ ironic node-set-provision-state UUID provide<br>
  # wait<br>
<br>
For Kilo it would simply move node to MANAGEABLE and back to AVAILABLE.<br>
<br>
Important side note: some people don't realize that ALL provision state<br>
transitions are asynchronous. And all of them can fail! Even if "manage"<br>
action was seemingly instant and synchronous before 1.11, it was not.<br>
Now with 1.11 API in place "manage" action may take substantial time and<br>
may fail. Make sure your tooling account for it.<br>
<br>
Now it's up to the ironic team to decide [2] whether and when we're<br>
bumping ironicclient default API version to something above 1.11. Opinions?<br>
<br>
[1] <a href="https://review.openstack.org/#/c/194722/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/194722/</a><br>
[2] <a href="https://review.openstack.org/#/c/196320/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/196320/</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div></div>