[openstack-dev] [oslo] documentation on using the oslo.db opportunistic test feature
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:
>>> You need to set the env variable like so. See testenv:mysql-python
>>> for example
>> 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.
More information about the OpenStack-dev