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

Reply via email to