<div dir="ltr">It sounds like we all agree -- the client we ship should default to a fixed, older version. Anyone who wants newer functionality can pass a newer version to their client.<div><div><br></div><div>Here's the current state of things:</div><div><br></div><div>server:</div><div>- stable/kilo: 1.6</div><div>- current: 1.11</div><div><br></div><div>client:</div><div>- stable/kilo: 1.6</div><div>- latest release (0.7.0): 1.6</div><div>- current: 1.9</div><div><br></div><div>So -- since we haven't released a client that sends a header > 1.6, I propose that we set the client back to sending the 1.6 header right away. While having the client default to 1.1 would be ideal, this should still keep the "Jackson the Absent" of the world as happy as reasonably possible moving forward without breaking anyone that is packaging Kilo already.</div><div><br></div><div>(yes, this may affect Olivia the Contributor, but that's OK because Olivia will have read this email :) )</div><div><br></div><div>-Deva</div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 31, 2015 at 2:50 PM Jim Rollenhagen <<a href="mailto:jim@jimrollenhagen.com" target="_blank">jim@jimrollenhagen.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Jul 31, 2015 at 02:37:52PM -0700, Clint Byrum wrote:<br>
> Excerpts from Sean Dague's message of 2015-07-31 04:14:54 -0700:<br>
> > On 07/30/2015 04:58 PM, Devananda van der Veen wrote:<br>
> > <snip><br>
> > >     Thoughts?<br>
> > ><br>
> > >     * I'm assuming it is possible to make micro version changes to the<br>
> > >     1.x API<br>
> > >       as 1.10.1, 1.10.2,etc<br>
> > ><br>
> > ><br>
> > > Despite most folks calling this "microversions", I have been trying to<br>
> > > simply call this "API version negotiation".<br>
> > ><br>
> > > To your question, no -- the implementations by Nova and Ironic, and the<br>
> > > proposal that the API-WG has drafted [1], do not actually support<br>
> > > MAJOR.MINOR.PATCH semantics.<br>
> > ><br>
> > > It has been implemented as a combination of an HTTP request to<br>
> > > "http(s)://<server URL>/<major>/<resource URI>" plus a<br>
> > > header "X-OpenStack-<service>-API-Version: <major>.<minor>".<br>
> > ><br>
> > > The <major> version number is duplicated in both the URI and the header,<br>
> > > though Ironic will error if they do not match. Also, there is no <patch><br>
> > > or <micro> version.<br>
> > ><br>
> > > So, were we to change the <major> version in the header, I would expect<br>
> > > that we also change it in the URL, which means registering a new<br>
> > > endpoint with Keystone, and, well, all of that.<br>
> ><br>
> > Right, it's important to realize that the microversion mechanism is not<br>
> > semver, intentionally. It's inspired by HTTP content negotiation, as<br>
> > Deva said. I wrote up a lot of the rational for the model in Nova here,<br>
> > which the Ironic model is based off of -<br>
> > <a href="https://dague.net/2015/06/05/the-nova-api-in-kilo-and-beyond-2/" rel="noreferrer" target="_blank">https://dague.net/2015/06/05/the-nova-api-in-kilo-and-beyond-2/</a><br>
> ><br>
><br>
> Thanks Sean, this post was exactly what I needed to understand the<br>
> inspiration behind the current situation.<br>
><br>
> > Ironic is a little different. It's entirely an admin API. And most users<br>
> > are going to only talk to an Ironic that they own the deployment<br>
> > schedule on. So the multi cloud that you don't own concern might not be<br>
> > there. But, it would also be confusing to all users if Ironic goes down<br>
> > a different path with microversions, and still calls it the same thing.<br>
> ><br>
><br>
> I think being single-tenant makes the impact of changes different,<br>
> however the solution can be the same. While tools that use Ironic may<br>
> not be out in the wild as much from an operator perspective, there will<br>
> be plenty of tools built to the Ironic API that will want to be<br>
> distributed to users of various versions of Ironic.<br>
><br>
> It sounds to me like for Ironic, the same assumption should be made as<br>
> in the outlined "Jackson the Absent" solution. Assume no version is old<br>
> version, and require specifying the new version to get any new behavior.<br>
><br>
> What is preventing Ironic from embracing that?<br>
<br>
So, this is actually how the Ironic API behaves. However, it was at some<br>
point decided that the client should have a more recent default version<br>
(which is the main topic for this thread).<br>
<br>
I agree with you; I think this is the best route.<br>
<br>
// jim<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>