2015-04-28 15:22 GMT+08:00 Alex Xu <sou...@gmail.com>: > > > 2015-04-27 17:49 GMT+08:00 John Garbutt <j...@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 <sou...@gmail.com> wrote: >> > 2015-04-24 18:15 GMT+08:00 Andrey Kurilin <akuri...@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 <sou...@gmail.com> wrote: >> >>> >> >>> >> >>> >> >>> 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: >> >>>>>> >> >>>>>> 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-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 >> >>> >> >> >> >> >> >> >> >> -- >> >> 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 >> > >> >> __________________________________________________________________________ >> 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