Open Stack

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

-- 
Sean Dague
http://dague.net