[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