Thank you for suggestions! I'll try modify patches as soon as possible. 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