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

Sean Dague sean at dague.net
Tue Feb 23 17:20:50 UTC 2016

On 02/23/2016 11:29 AM, Mike Bayer wrote:
> 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.

Ok, well it was invented somewhere after it was extracted from Nova. :)

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

2 thoughts on that:

1) Being able to do a grant with a prefix like

GRANT all on 'openstack_ci%'.* to openstack_citest

Then using that prefix in the random db generation. That would at least
limit scope. That seems the easiest to do with the existing infrastructure.

2) Have a set of stack dbs with openstack_citest## where # is number,
and the testr worker id is used to set the number.

That would be more like the static accounts model used in Tempest.


Sean Dague

More information about the OpenStack-dev mailing list