[openstack-dev] [oslo] documentation on using the oslo.db opportunistic test feature

Mike Bayer mbayer at redhat.com
Tue Feb 23 16:29:06 UTC 2016



On 02/22/2016 08:18 PM, Sean Dague wrote:
> On 02/22/2016 08:08 PM, Davanum Srinivas wrote:
>> Sean,
>>
>> You need to set the env variable like so. See testenv:mysql-python for example
>> OS_TEST_DBAPI_ADMIN_CONNECTION=mysql://openstack_citest:openstack_citest@localhost
>>
>> Thanks,
>> Dims
>>
>> [1] http://codesearch.openstack.org/?q=OS_TEST_DBAPI_ADMIN_CONNECTION&i=nope&files=&repos=
>
> If I am reading this correctly, this needs full access to the whole
> mysql administratively?

the openstack_citest user needs permission to create and use new 
databases when the multiprocessing feature of testr is used.   This is 
not a new requirement and the provisioning refactor in oslo.db did not 
invent this.



>
> Is that something that could be addressed? In many of my environments
> the mysql db does other things as well, so giving full admin to
> arbitrary test code is a bit concerning.

I'd suggest that running any test suite against a database that is used 
for other things is not an optimal practice; test suites by definition 
can break things.   Even if the test suite user has limited permissions, 
there's still many ways a bad test can break your database even though 
it's less likely.   Running an additional mysql server against an 
alternate data directory with a different port is one option here.


  Tempest ran into a similar
> issue and addressed this by allowing for preallocation of accounts. That
> kind of approach seems like it would work here given that you could do
> grants on well known names.

This is a feature that could be supported by oslo.db provisioning. 
Right now the multi-process provisioning is hardcoded to use random 
names but certainly options or environment variables can be established 
that it would work among.    But you'd have to ensure that multiple test 
suites aren't using the same set of names at the same time.

Feel free to suggest the preferred system of establishing these 
pre-defined database names and I or someone else (since im on PTO all 
next week) can work something up.




>
> 	-Sean
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



More information about the OpenStack-dev mailing list