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

Sean Dague 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[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.

Yes, absolutely.

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
checking things.

I think these are the kind of changes that help ensure a solid Icehouse
release.

Thanks Kenichi!

	-Sean

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140311/8e0989d2/attachment.pgp>


More information about the OpenStack-dev mailing list