Open Stack

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 <soulxu at gmail.com> wrote:

>
>
> 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
>>
>>
>
> __________________________________________________________________________
> 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/b966e1eb/attachment.html>