[openstack-dev] [qa] Tempest review and development priorities until release
sean at dague.net
Tue Mar 11 14:01:40 UTC 2014
On 03/11/2014 09:48 AM, Kenichi Oomichi wrote:
> 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.
> 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.
I would count the API response checks in the Additional posititive API /
scenario tests for integrated projects. I should have been clear that it
also means enhancements of those tests that ensures they are properly
I think these are the kind of changes that help ensure a solid Icehouse
Samsung Research America
sean at dague.net / sean.dague at samsung.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 482 bytes
Desc: OpenPGP digital signature
More information about the OpenStack-dev