On 02/24/2015 06:55 AM, Ken'ichi Ohmichi wrote:
Hi Ghanshyam,
2015-02-24 20:28 GMT+09:00 GHANSHYAM MANN <ghanshyamm...@gmail.com>:
On Tue, Feb 24, 2015 at 6:48 PM, Ken'ichi Ohmichi <ken1ohmi...@gmail.com>
wrote:
Hi
Nova team is developing Nova v2.1 API + microversions in this cycle,
and the status of Nova v2.1 API has been changed to CURRENT from
EXPERIMENTAL.
That said new API properties should be added via microversions, and
v2/v2.1 API(*without* microversions) should return the same response
without any new properties.
Now Tempest allows extra properties of a Nova API response because we
thought Tempest should not block Nova API development.
However, I think Tempest needs to deny extra properties in
non-microversions test cases because we need to block accidental
changes of v2/v2.1 API and encourage to use microversions for API
changes.
https://review.openstack.org/#/c/156130/ is trying to do that, but I'd
like to get opinions before that.
If the above change is merged, we can not use Tempest on OpenStack
environments which provide the original properties.
I think that will be nice to block additional properties.
Do you mean OpenStack environment with micro-versions enabled?
In those cases too tempest should run successfully as it requests on V2 or
V2.1 endpoint not on microversion.
My previous words were unclear, sorry.
The above "OpenStack environment" means the environment which is
customized by a cloud service provider and it returns a response which
includes the provider original properties.
On microversions discussion, we considered the customized API by
a cloud service provider for the design. Then I guess there are some
environments return extra properties and Tempest will deny them if
the patch is merged. I'd like to know the situation is acceptable or not
as Tempest purpose.
Ken'ichi, can you please provide a pointer to the referenced
microversions discussion and/or summarize the conclusion?
The commit message is saying that returning extra values without a new
microversion is an incompatible (disallowed) change. This was already
true, unless creating a new extension, according to
https://wiki.openstack.org/wiki/APIChangeGuidelines.
Seems to me that extra properties (unless using a syntax marking them as
such), are either allowed or not. If not, tempest should fail on them.
If service providers are allowed to add returned properties, and not
required to use some special syntax to distinguish them, that is a bad
api. If tempest can't tell the difference between a legitimate added
property and some one misspelling while returning an optional property,
I'm not sure how we test for the unintentional change case.
-David
Thanks
Ken Ohmichi
__________________________________________________________________________
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
