Open Stack

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