[openstack-dev] [qa][keystone] Adding client library related tests to tempest

Sean Dague sean at dague.net
Sat Oct 19 11:30:50 UTC 2013


On 10/18/2013 09:10 PM, Adam Young wrote:
> On 10/18/2013 07:21 PM, Sean Dague wrote:
>> On 10/18/2013 05:09 PM, Dolph Mathews wrote:
>>>
>>> On Fri, Oct 18, 2013 at 3:19 PM, David Stanek <dstanek at dstanek.com
>>> <mailto:dstanek at dstanek.com>> wrote:
>>>
>>>
>>>     On Fri, Oct 18, 2013 at 1:48 PM, Sean Dague <sean at dague.net
>>>     <mailto:sean at dague.net>> wrote:
>>>
>>>         On 10/18/2013 12:04 PM, Brant Knudson wrote:
>>>
>>>
>>>             2) "git clone"ing the keystoneclient doesn't work well with
>>>             parallel
>>>             testing (we have a similar problem in our tests with our
>>>             "pristine"
>>>             database backup)
>>>
>>>
>>>         Can you go into the specifics of why?
>>>
>>>
>>>     We use unsafe paths for the test SQLite database and test config
>>>     files.  Instead of using something like tempfile we are using
>>>     hardcoded paths.  When the setUp method is run in parallel it will
>>>     stomp on other tests.  I believe the 'git clone' is the same way.
>>>       The clone happens in the setUp so if you have 2 test methods in
>>>     that test class one of the cloning operations will break.
>>>
>>>     I have a bug filed for the DB/config file issue already. The
>>>     cloning issue may solved by putting it into the setupClass instead
>>>     of setUp.  I'd have to try it.
>>>
>>>
>>> test_keystoneclient is really an integration test between the client &
>>> server, but expecting internet access to run the tests in keystone's own
>>> repo has been a long-standing complaint (although this bug was only
>>> recently filed):
>>> https://bugs.launchpad.net/keystone/+bug/1191999
>>
>> Ok, cool. It sounds like we actually should probably talk through
>> what's all needed to do this right for keystone at summit, especially
>> as we're talking about creating a new class of tests for it. Can
>> someone propose a session for it in the QA track?
>>
>> I think many of us were caught off guard by the patch as typically
>> we're pretty deliberate about structure in the tree, and it hadn't yet
>> come up at a QA meeting. So a summit session probably could get us all
>> agreed on a plan moving forward and make sure we figure out all the
>> needs of keystone here. I do think it might warrant uniqueness given
>> that *all* the other services need it.
>>
>>     -Sean
>>
> Done
> http://summit.openstack.org/cfp/details/313

Accepted. See you there.

	-Sean

-- 
Sean Dague
http://dague.net



More information about the OpenStack-dev mailing list