Open Stack

Thank you for suggestions! I'll try modify patches as soon as possible.

On Fri, Apr 24, 2015 at 6:56 AM, Alex Xu <soulxu at 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 <akurilin at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150424/d2937b2e/attachment.html>