[openstack-dev] [qa] Tempest review and development priorities until release

Kenichi Oomichi oomichi at mxs.nes.nec.co.jp
Tue Mar 11 13:48:52 UTC 2014

Hi Sean,

> -----Original Message-----
> From: Sean Dague [mailto:sean at dague.net]
> Sent: Tuesday, March 11, 2014 10:06 PM
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] [qa] Tempest review and development priorities until release
> Tempest has no feature freeze in the same way as the core projects, in a
> lot of ways some of our most useful effort happens right now, as
> projects shore up features within the tempest code.
> That being said, the review queue remains reasonably large, so I would
> like to focus review attention on items that will make a material impact
> on the quality of the Icehouse release.
> That means I'd like to *stop* doing patches and reviews that are
> internal refactorings. We can start doing those again in Juno. I know
> there were some client refactorings, and hacking cleanups in flight.
> Those should wait until Icehouse is released.
> From my perspective the top priorities for things to be reviewed /
> developed are:
>  * Heat related tests (especially on the heat slow job) as we're now
> gating with that, but still only have 1 real test
>  * Changes to get us Neutron full support (I actually think the tempest
> side is complete, but just in case)
>  * Unit tests of Tempest function (so we know that we are doing the
> things we think)
>  * Bugs in Tempest itself
>  * The Keystone multi auth patches (so was can actually test v3)
>  * Any additional positive API / scenario tests for *integrated*
> projects (incubated projects are currently best effort).

I got it, and I'd like to clarify whether one task is acceptable or not.

In most test cases, Tempest does not check API response body(API attributes).
Now I am working for improving API attribute test coverage for Nova API[1].
I think the task is useful for the backward compatibility and finding some
latent bags(API sample files etc). In addition, this improvement is necessary
to prove the concept of Nova "v2.1" API because the we need to check v2.1 API
does not cause backward incompatibility issues.

Can we continue this improvement?
Of course, I will do review for the above areas(Heat, etc) also.

Ken'ichi Ohmichi

[1]: https://blueprints.launchpad.net/tempest/+spec/nova-api-attribute-test

More information about the OpenStack-dev mailing list