Re: [openstack-dev] [nova][api] How to handle API changes in contrib/*.py
Ping. Chris, Alex, Ken, do we have an answer to Claudiu's questions below? On 02/02/2015 05:51 PM, Claudiu Belu wrote: Hello! There have been some discussion on what nova-api should return after a change in the API itself. So, the change that generated this discussion is an API change to 2.2 is: https://review.openstack.org/#/c/140313/23 - **2.2** Added Keypair type. A user can request the creation of a certain 'type' of keypair (ssh or x509). If no keypair type is specified, then the default 'ssh' type of keypair is created. Currently, this change was done on *plugins/v3/keypairs.py*, so now, the 2.2 version will also return the keypair type on keypair-list, keypair-show, keypair-create. Microversioning was used, so this behaviour is valid only if the user requests the 2.2 version. Version 2.1 will not accept keypair type as argument, nor will return the keypair type. Now, the main problem is *contrib/keypairs.py*, microversioning cannot be applied there. The current commit filters the keypair type, it won't be returned. But there have been reviews stating that returning the keypair type is a back-compatible change. Before this, there was a review stating that keypair type should not be returned. So, finally, my question is: how should the API change be handled in *contrib/keypairs.py*? Best regards, Claudiu Belu __ 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
Re: [openstack-dev] [nova][api] How to handle API changes in contrib/*.py
Hi Claudiu, 2015-02-03 7:51 GMT+09:00 Claudiu Belu cb...@cloudbasesolutions.com: There have been some discussion on what nova-api should return after a change in the API itself. So, the change that generated this discussion is an API change to 2.2 is: https://review.openstack.org/#/c/140313/23 - **2.2** Added Keypair type. A user can request the creation of a certain 'type' of keypair (ssh or x509). If no keypair type is specified, then the default 'ssh' type of keypair is created. Currently, this change was done on plugins/v3/keypairs.py, so now, the 2.2 version will also return the keypair type on keypair-list, keypair-show, keypair-create. Microversioning was used, so this behaviour is valid only if the user requests the 2.2 version. Version 2.1 will not accept keypair type as argument, nor will return the keypair type. The above behavior seems reasonable from experience of microversions discussion. Now, the main problem is contrib/keypairs.py, microversioning cannot be applied there. The current commit filters the keypair type, it won't be returned. But there have been reviews stating that returning the keypair type is a back-compatible change. Before this, there was a review stating that keypair type should not be returned. So, finally, my question is: how should the API change be handled in contrib/keypairs.py? I think v2 API(contrib/keypairs.py) should not return the keypair type basically. Before microversions, when adding new parameters which is backwards *compatible*, we need to add dummy extension for noticing the change to clients. For example, you can see server_group_quotas[1] extension which is almost empty and base extension server_group switches its behavior based on server_group_quotas extension loading condition. [2] So if keypair type needs to be returned, we need to add this kind of dummy extension to v2(under contrib/). but this development manner makes non-important code. That is one of reasons why we are implementing microversions for avoiding dummy extensions. Thanks Ken Ohmichi --- [1]: https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/contrib/server_group_quotas.py [2]: https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/contrib/server_groups.py#L196 __ 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
Re: [openstack-dev] [nova][api] How to handle API changes in contrib/*.py
Bump. Also, added to CC Alex Xu and Chris Yeoh. Cheers! Claudiu Belu From: Claudiu Belu [cb...@cloudbasesolutions.com] Sent: Tuesday, February 03, 2015 12:51 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [nova][api] How to handle API changes in contrib/*.py Hello! There have been some discussion on what nova-api should return after a change in the API itself. So, the change that generated this discussion is an API change to 2.2 is: https://review.openstack.org/#/c/140313/23 - **2.2** Added Keypair type. A user can request the creation of a certain 'type' of keypair (ssh or x509). If no keypair type is specified, then the default 'ssh' type of keypair is created. Currently, this change was done on plugins/v3/keypairs.py, so now, the 2.2 version will also return the keypair type on keypair-list, keypair-show, keypair-create. Microversioning was used, so this behaviour is valid only if the user requests the 2.2 version. Version 2.1 will not accept keypair type as argument, nor will return the keypair type. Now, the main problem is contrib/keypairs.py, microversioning cannot be applied there. The current commit filters the keypair type, it won't be returned. But there have been reviews stating that returning the keypair type is a back-compatible change. Before this, there was a review stating that keypair type should not be returned. So, finally, my question is: how should the API change be handled in contrib/keypairs.py? Best regards, Claudiu Belu __ 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
Re: [openstack-dev] [nova][api] How to handle API changes in contrib/*.py
I have failed to add Chris Yeoh. Hope it's fine now.. From: Claudiu Belu [cb...@cloudbasesolutions.com] Sent: Wednesday, February 04, 2015 5:10 PM To: OpenStack Development Mailing List (not for usage questions) Cc: x...@linux.vnet.ibm.com Subject: Re: [openstack-dev] [nova][api] How to handle API changes in contrib/*.py Bump. Also, added to CC Alex Xu and Chris Yeoh. Cheers! Claudiu Belu From: Claudiu Belu [cb...@cloudbasesolutions.com] Sent: Tuesday, February 03, 2015 12:51 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [nova][api] How to handle API changes in contrib/*.py Hello! There have been some discussion on what nova-api should return after a change in the API itself. So, the change that generated this discussion is an API change to 2.2 is: https://review.openstack.org/#/c/140313/23 - **2.2** Added Keypair type. A user can request the creation of a certain 'type' of keypair (ssh or x509). If no keypair type is specified, then the default 'ssh' type of keypair is created. Currently, this change was done on plugins/v3/keypairs.py, so now, the 2.2 version will also return the keypair type on keypair-list, keypair-show, keypair-create. Microversioning was used, so this behaviour is valid only if the user requests the 2.2 version. Version 2.1 will not accept keypair type as argument, nor will return the keypair type. Now, the main problem is contrib/keypairs.py, microversioning cannot be applied there. The current commit filters the keypair type, it won't be returned. But there have been reviews stating that returning the keypair type is a back-compatible change. Before this, there was a review stating that keypair type should not be returned. So, finally, my question is: how should the API change be handled in contrib/keypairs.py? Best regards, Claudiu Belu __ 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
