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

Mike Bayer mbayer at redhat.com
Tue Feb 23 17:26:20 UTC 2016



On 02/23/2016 12:20 PM, Sean Dague wrote:
> 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.

a prefix would be very easy, and I almost wonder if we should just have 
an identifiable prefix on the username in all cases anyway.   However, 
the wildcard scheme here is only useful on MySQL.  Other backends don't 
support such a liberal setting.


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



More information about the OpenStack-dev mailing list