There are no so much messages, since first mail was published 2 weeks ago, so I don't want spend a lot of time waiting comments, which may not appear.
Btw, some questions appeared in my head related to your suggestions:) >When user execute cmd without --os-compute-version. The nova client should discover the nova server >supported version. Then cmd choice the latest version supported both by client and server. In that case, why X-Compute-API-Version can accept "latest" value? Also, such discovery will require extra request to API side for every client call. >'--os-compute-version=None' can be supported, that means will return the min version of server supported. >From my point of view '--os-compute-version=None' is equal to not specified value. Maybe, it would be better to accept value "min" for os-compute-version option. >The supported version can be discovered by version API (Thanks to Ken'ichi fix this): Yeah. I saw his patch to novaclient, which adds ability to display supported microversions - https://review.openstack.org/#/c/173711/ >3. if the microversion non-supported, but user call cmd with --os-compute-version, this should return failed. Imo, it should be implemented on API side(return BadRequest when X-Compute-API-Version header is presented in V2) On Fri, Apr 24, 2015 at 12:42 PM, Alex Xu <sou...@gmail.com> wrote: > > > 2015-04-24 17:24 GMT+08:00 Andrey Kurilin <akuri...@mirantis.com>: > >> Thank you for suggestions! I'll try modify patches as soon as possible. >> > > np, it's better waiting for more comment before you begin to update the > code first. avoid you need rework again I think :) > > >> >> On Fri, Apr 24, 2015 at 6:56 AM, Alex Xu <sou...@gmail.com> wrote: >> >>> Thanks Andrey for hard work on the microverison client support. >>> >>> Wrote down some my thought: >>> >>> I also agreed we will have only one endpoint 'compute'. Hope we can >>> switch v2.1 export as '/v2' in the api-paste.conf as default very soon~ >>> >>> let's say what expected after we only have v2.1 in the world first: >>> >>> There are two cases for use nova client. >>> 1. user use nova client command line. I think command line should >>> support version discover. Provide most convenient way let the user try nova. >>> 2. user use nova client as library. user should call the client code to >>> discover the version and decided what version he want to use by himself. >>> >>> For the command line, the behavior can be: >>> >>> When user execute cmd without --os-compute-version. The nova client >>> should discover the nova server supported version. Then cmd choice the >>> latest version supported both by client and server. This is good for us to >>> introduce the new feature to the user. >>> >>> Also user can specified a version he want to by --os-compute-version. >>> >>> '--os-compute-version=None' can be supported, that means will return the >>> min version of server supported. >>> >>> The supported version can be discovered by version API (Thanks to >>> Ken'ichi fix this): >>> GET '/' >>> >>> https://github.com/openstack/nova/blob/master/doc/api_samples/versions/versions-get-resp.json#L25 >>> >>> But reality is the v2 and v2.1 will existed at same time. >>> >>> So the v2 or v2.1 code both can run under the endpoint 'compute' with >>> url '/v2'. It depend on the admin's deployment. >>> >>> So I think the cmd also can discover whether the api supported >>> microversion under the 'compute' endpoint. >>> >>> This can be discovered by version api also. >>> >>> GET '/v2/' will return the endpoint version info. Then we can check the >>> version and min_version properties to know whether the api support >>> microversion or not. >>> >>> The behavior can be: >>> 1. If the microversion supported, the cmd behavior is same as the >>> description at the top of this mail >>> 2. If the microversion non-supported, user call cmd without >>> --os-compute-version, we use the min version. >>> 3. if the microversion non-supported, but user call cmd with >>> --os-compute-version, this should return failed. >>> >>> Hope those thoughts are helpful. >>> >>> Looks like this need some change in current patchset also :( I know >>> Andrey already pay lot of on this. But if we like this way, I also can give >>> some help on the coding :) >>> >>> Thanks >>> Alex >>> >>> >>> 2015-04-10 19:30 GMT+08:00 Andrey Kurilin <akuri...@mirantis.com>: >>> >>>> Hi all! >>>> I working on implementation of support microversions in novaclient. >>>> Patches are ready for review, but there is one opened question: what we >>>> should do with v2.1 endpoint(computev21 service type)? >>>> >>>> "compute" is a default value of service type and keystone returns v2 >>>> api endpoint for it(at least in devstack), so version header will be >>>> ignored on API side. >>>> >>>> On the one hand, each deployment can have it's own configuration of >>>> service catalog and endpoints, so default value of service type should be >>>> strict and support as much deployments as we can. On the other hand, >>>> dependency of service type for microversion feature is not good and >>>> end-users should not take care about choice of correct service type when >>>> they want to execute simple command. >>>> >>>> Possible solutions: >>>> >>>> 1. leave everything as is: use "--service-type computev21" for each >>>> microversioned command >>>> 2. move default value of service type to environment >>>> variables(default value is hardcoded in novaclient code now) >>>> 3. add additional option --compute-api-type. Proposed etherpad by >>>> Christopher Yeoh >>>> https://etherpad.openstack.org/p/novaclient_microversions_design . >>>> Implementation is already finished - >>>> https://review.openstack.org/#/c/167577/ . This proposal still >>>> requires addition cli option, but compute-api-type looks more >>>> user-friendly >>>> >>>> >>>> Current implementation uses "compute" as default value for service >>>> type. Patches are pass all gates, except stable branches and ready for >>>> review: >>>> >>>> - https://review.openstack.org/#/c/169378/ - deprecate v1.1 and >>>> remove references to v3 in code >>>> - https://review.openstack.org/#/c/152569/ - Implements >>>> 'microversions' api type - Part 1 (usage of >>>> nova.api.openstack.api_version_request:APIVersionRequest class with >>>> https://review.openstack.org/#/c/169292/ ) >>>> - https://review.openstack.org/#/c/167408/ - Implements >>>> 'microversions' api type - Part 2 (adds new decorators and substitution >>>> mechanism using nova.api.openstack.versioned_method ) >>>> - https://review.openstack.org/#/c/136458/ - Implementation of 2.2 >>>> microversion >>>> >>>> >>>> -- >>>> 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 >>> >>> >> >> >> -- >> 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 > > -- 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
