Re: [openstack-dev] [nova][qa] Compatibility of extra values returned in json dicts and headers

2014-04-20 Thread Kenichi Oomichi 
Hi David,

Thanks for pointing it up.

 -Original Message-
 From: David Kranz [mailto:dkr...@redhat.com]
 Sent: Saturday, April 19, 2014 4:16 AM
 To: OpenStack Development Mailing List
 Subject: [openstack-dev] [nova][qa] Compatibility of extra values returned in 
 json dicts and headers
 
 Recently, as a result of the nova 2.1/3.0 discussion, tempest has been
 adding validation of the json dictionaries and headers returned by nova
 api calls. This is done by specifying json schema for these values.
 As proposed, these schema do not specify additionalProperties: False,
 which means that if a header is added or a new key is added to a returned
 dict, the tempest test will not fail. The current api change guidelines
 say this:
 
 Generally Considered OK
 * The change is the only way to fix a security bug
 * Fixing a bug so that a request which resulted in an error response
   before is now successful
 * Adding a new response header
 * Changing an error response code to be more accurate
 * OK when conditionally added as a new API extension
   * Adding a property to a resource representation
   * Adding an optional property to a resource representation which may
 be supplied by clients, assuming the API previously would ignore this 
 property
 
 This seems to say that you need an api extension to add a value to a
 returned dict but not to add a new header. So that would imply that
 checking the headers should allow additional properties but checking
 the body should not. Is that the desired behavior?

On  Generally Not Acceptable of 
https://wiki.openstack.org/wiki/APIChangeGuidelines ,
the above case is not mentioned. So I'm not sure we have already gotten
a consensus that we should not allow additional properties of response bodies.
I has gotten this point twice through patch reivews. Just IMO, it is OK to
extend response bodies with additional properties. That means 
additionalProperties
should be True in JSONSchema definitions.
The removal/rename of properties cause backward incompatibility issues and
Tempest needs to block these changes, but additional properties don't cause
the issues and clients should be assumed to ignore them if not necessary.

This is just my opinion, and it is not strong one. So I also know some
feedbacks about this.


Thanks
Ken'ichi Ohmichi

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][qa] Compatibility of extra values returned in json dicts and headers

2014-04-18 Thread David Kranz 
Recently, as a result of the nova 2.1/3.0 discussion, tempest has been 
adding validation of the json dictionaries and headers returned by nova 
api calls. This is done by specifying json schema for these values. As 
proposed, these schema do not specify additionalProperties: False, 
which means that if a header is added or a new key is added to a 
returned dict, the tempest test will not fail. The current api change 
guidelines say this:



 Generally Considered OK

 * The change is the only way to fix a security bug
 * Fixing a bug so that a request which resulted in an error response
   before is now successful
 * Adding a new response header
 * Changing an error response code to be more accurate
 * OK when conditionally added as a new API extension
 o Adding a property to a resource representation
 o Adding an optional property to a resource representation which
   may be supplied by clients, assuming the API previously would
   ignore this property


This seems to say that you need an api extension to add a value to a 
returned dict but not to add a new header. So that would imply that 
checking the headers should allow additional properties but checking the 
body should not. Is that the desired behavior? Would there be harm in 
allowing values to be added to a returned dict as well as the headers? 
Saying that application code should check if there is an extension to 
add a new value before trying to use the value seems pretty close to 
just checking for the existence of the value. In any event, we need to 
decide what the correct value is for these schemas.


 -David
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev