Open Stack

2015-04-24 17:24 GMT+08:00 Andrey Kurilin <akurilin at 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 <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.
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150424/d0d73db1/attachment.html>