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
