Open Stack

# Sorry for sending this again, previous mail was unreadable.

2014-04-28 11:54 GMT+09:00 Ken'ichi Ohmichi <ken1ohmichi at gmail.com>:
>>
>> This is also why there are a bunch of nova v2 extensions that just add
>> properties to an existing API. I think in v3 the proposal was to do this with
>> microversioning of the plugins. (we don't have a way to configure
>> microversioned v3 api plugins in tempest yet, but we can cross that bridge when
>> the time comes) Either way it will allow tempest to have in config which
>> behavior to expect.
>
> Good point, my current understanding is:
> When adding new API parameters to the existing APIs, these parameters should
> be API extensions according to the above guidelines. So we have three options
> for handling API extensions in Tempest:
>
> 1. Consider them as optional, and cannot block the incompatible
> changes of them. (Current)
> 2. Consider them as required based on tempest.conf, and can block the
> incompatible changes.
> 3. Consider them as required automatically with microversioning, and
> can block the incompatible changes.

I investigated the way of the above option 3, then have one question
about current Tempest implementation.

Now verify_tempest_config tool gets API extension list from each
service including Nova and verifies API extension config of tempest.conf
based on the list.
Can we use the list for selecting what extension tests run instead of
the verification?
As you said In the previous IRC meeting, current API tests will be
skipped if the test which is decorated with requires_ext() and the
extension is not specified in tempest.conf. I feel it would be nice
that Tempest gets API extension list and selects API tests automatically
based on the list.
In addition, The methods which are decorated with requires_ext() are
test methods now, but I think it would be better to decorate client
methods(get_hypervisor_list, etc.) because each extension loading
condition affects available APIs.

Thanks
Ken'ichi Ohmichi