2015-06-17 19:46 GMT+08:00 Andrey Kurilin <akuri...@mirantis.com>: > Why does alternative implementation need to implement all 50 versions? > As far as I understand, API side should not support all versions, that is > why version info returns min and max versions > https://github.com/openstack/nova/blob/master/doc/api_samples/versions/versions-get-resp.json#L25-L26 >
If we raise min_versions randomly...that may means we have 50 back-incompatible APIs in the world. So min_version will be raise rarely for keep back-compatible > > > On Tue, Jun 16, 2015 at 11:36 AM, Alex Xu <sou...@gmail.com> wrote: > >> >> >> 2015-06-16 5:24 GMT+08:00 Clint Byrum <cl...@fewbar.com>: >> >>> Excerpts from Sean Dague's message of 2015-06-15 14:00:43 -0700: >>> > On 06/15/2015 04:50 PM, Jim Rollenhagen wrote: >>> > > On Mon, Jun 15, 2015 at 01:07:39PM -0400, Jay Pipes wrote: >>> > >> It has come to my attention in [1] that the microversion spec for >>> Nova [2] >>> > >> and Ironic [3] have used the project name -- i.e. Nova and Ironic >>> -- instead >>> > >> of the name of the API -- i.e. "OpenStack Compute" and "OpenStack >>> Bare >>> > >> Metal" -- in the HTTP header that a client passes to indicate a >>> preference >>> > >> for or knowledge of a particular API microversion. >>> > >> >>> > >> The original spec said that the HTTP header should contain the name >>> of the >>> > >> service type returned by the Keystone service catalog (which is >>> also the >>> > >> official name of the REST API). I don't understand why the spec was >>> changed >>> > >> retroactively and why Nova has been changed to return >>> > >> X-OpenStack-Nova-API-Version instead of >>> X-OpenStack-Compute-API-Version HTTP >>> > >> headers [4]. >>> > >> >>> > >> To be blunt, Nova is the *implementation* of the OpenStack Compute >>> API. >>> > >> Ironic is the *implementation* of the OpenStack BareMetal API. >>> > > >>> > > While I tend to agree in principle, do we reasonably expect that >>> other >>> > > implementations of these APIs will implement every one of these >>> > > versions? Can we even reasonably expect another implementation of >>> these >>> > > APIs? >>> > > >>> > > // jim >>> > >>> > Yeh, honestly, I'm not really convinced that thinking we are doing this >>> > for alternative implementations is really the right approach (or even >>> > desireable). Honestly, the transition to microversions makes >>> alternative >>> > implementations harder because there isn't a big frozen API for a long >>> > period of time. >>> > >>> >>> Actually that makes an alternative implementation more valuable. Without >>> microversions those alternative implementations would have to wait a long >>> time to implement fixes to the API, but now can implement and publish >>> the fix as soon as the microversion lands. This means that alternative >>> implementations will lag _less_ behind the primary. >>> >> >> So if our min_version is 2.1 and the max_version is 2.50. That means >> alternative implementations need implement all the 50 versions api...that >> sounds pain... >> >> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Best regards, > Andrey Kurilin. > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev