[openstack-dev] [nova][python-novaclient] microversion implementation on client side
Alex Xu
soulxu at gmail.com
Tue Apr 28 07:25:03 UTC 2015
2015-04-28 15:22 GMT+08:00 Alex Xu <soulxu at gmail.com>:
>
>
> 2015-04-27 17:49 GMT+08:00 John Garbutt <john at johngarbutt.com>:
>
>> I see these changes as really important.
>>
>> We need to establish good patterns other SDKs can copy.
>>
>> On 24 April 2015 at 12:05, Alex Xu <soulxu at gmail.com> wrote:
>> > 2015-04-24 18:15 GMT+08:00 Andrey Kurilin <akurilin at mirantis.com>:
>> >> >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.
>> >>
>> >
>> > I think it is convenient for some case. like give user more easy to try
>> nova
>> > api by some code access the nova api directly. Yes, it need one more
>> extra
>> > request. But if without discover, we can't ensure the client support
>> server.
>> > Maybe client too old for server even didn't support the server's min
>> > version. For better user experience, I think it worth to discover the
>> > version. And we will call keystone each nova client cli call, so it is
>> > acceptable.
>>
>> We might need to extend the API to make this easier, but I think we
>> need to come up with a simple and efficient pattern here.
>>
>>
>> Case 1:
>> Existing python-novaclient calls, now going to v2.1 API
>>
>> We can look for the transitional entry of computev21, as mentioned
>> above, but it seems fair to assume v2.1 and v2.0 are accessed from the
>> same service catalog entry of "compute", by default (eventually).
>>
>> Lets be optimistic about what the cloud supports, and request "latest"
>> version from v2.1.
>>
>> If its a v2.0 only API endpoint, we will not get back a version header
>> with the response, we could error out if the user requested v2.x
>> min_version via the CLI parameters.
>>
>> In most cases, we get the latest return values, and all is well.
>
>
>>
>> Case 2:
>> User wants some info they know was added to the response in a specific
>> microversion
>>
>> We can request "latest" and error out if we don't get a new enough
>> version to meet the user's min requirement.
>>
>>
>> Case 3:
>> Adding support for a new request added in a microversion
>>
>> We could just send "latest" and assume the new functionality, then
>> raise an error when you get bad request (or similar), and check the
>> version header to see if that was the cause of the problem, so we can
>> say why it failed.
>>
>> If its supported, everything just works.
>>
>> If the user requests a specific version before it was supported, we
>> should error out as not supported, I guess?
>>
>> In a way it would be cleaner if we had a way for the client to say
>> "latest but requires 2.3", so you get a bad version request if your
>> minimum requirement is not respected, so its much clearer than
>> miss-interpreting random errors that you might generate. But I guess
>> its not totally required here.
>>
>>
>> Would all that work? It should avoid an extra API call to discover the
>> specific version we have available.
>>
>
> Another thought is send the client's latest version to the servers.
> Microversion support back-incompatible change, for the case old client vs
> new servers, will get more chance to failure.
> If the client's lastest version didn't supported, we can return error to
> the user. And I registered a bug few days ago, we can return some header to
> show supported version in server when the request failed.
> https://bugs.launchpad.net/nova/+bug/1443494 then we can get better error
> message to the user.
>
>
>>
>> >> >'--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.
>> >
>> > I think '--os-compute-version=None' means not specified version request
>> > header when send api request to server. The server behavior is if there
>> > isn't value specified, the min version will be used.
>>
>> --os-compte-version=v2 means no version specified I guess?
>>
>> Can we go back to the use cases here please?
>> What do the users need here and why?
>
>
>>
>> >> >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)
>>
>> V2 is already deployed now, and doesn't do that.
>>
>> No matter what happens we need to fix that.
>> >
>> > Emm.... I'm not sure. Because GET '/v2/' already can be used to discover
>> > microversion support or not. Sounds like add another way to support
>> > discover? And v2 api didn't return fault with some extra header, that
>> sounds
>> > like behavior and back-incompatible change.
>>
>> -1
>>
>> We should not use the URL to detect the version.
>> We have other ways to do that for a good reason.
>>
>
>
> Sorry, I didn't describe clearly at here. I'm not mean use URL to detect
> the version at here. I mean GET '/' will get response like this
> https://github.com/openstack/nova/blob/master/doc/api_samples/versions/versions-get-resp.json
>
> If send request GET '/v2', it will return the version info of the
> endpoint, then we can determine whether v2.1 or v2 running under the '/v2'
> endpoint.
>
> If the GET '/v2''s response is
> { "id": "v2.1", "links": [ { "href": "http://openstack.example.com/v2.1/",
> "rel": "self" } ], "status": "CURRENT", "version": "2.3", "min_version": "
> 2.1", "updated": "2013-07-23T11:33:21Z" }
>
>
>
Sorry, the wrong click, I didn't finish what I said....
If the GET '/v2''s response is:
{
"id": "v2.1",
"links": [
{
"href": "http://openstack.example.com/v2.1/",
"rel": "self"
}
],
"status": "CURRENT",
"version": "2.3",
"min_version": "2.1",
"updated": "2013-07-23T11:33:21Z"
}
It means the v2.1 running under the '/v2'
if the GET '/v2' response is:
{
"id": "v2.0",
"links": [
{
"href": "http://openstack.example.com/v2/",
"rel": "self"
}
],
"status": "SUPPORTED",
"version": "",
"min_version": "",
"updated": "2011-01-21T11:33:21Z"
}
It means the v2 running under the '/v2'
>
>
>>
>> Thanks,
>> John
>>
>>
>>
>> >> 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:
>> >>>>>>
>> >>>>>> leave everything as is: use "--service-type computev21" for each
>> >>>>>> microversioned command
>> >>>>>> move default value of service type to environment variables(default
>> >>>>>> value is hardcoded in novaclient code now)
>> >>>>>> 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.
>> >>
>> >>
>> __________________________________________________________________________
>> >> 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
>> >
>>
>> __________________________________________________________________________
>> 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/20150428/514933ee/attachment.html>
More information about the OpenStack-dev
mailing list