Open Stack

Hi Ghanshyam,

2015-02-24 20:28 GMT+09:00 GHANSHYAM MANN <ghanshyammann at gmail.com>:
>
> On Tue, Feb 24, 2015 at 6:48 PM, Ken'ichi Ohmichi <ken1ohmichi at 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.

Thanks
Ken Ohmichi