On 07/25/2016 12:55 PM, Carl Baldwin wrote:
On Fri, Jul 22, 2016 at 8:47 AM, Mike Bayer <mba...@redhat.com
<mailto:mba...@redhat.com>> wrote:



    On 07/22/2016 04:02 AM, Kevin Benton wrote:

        Now that we have switched to oslo.db for test provisioning the
        responsibility of choosing a location lands
        here:
        
https://github.com/openstack/oslo.db/blob/a79479088029e4fa51def91cb36bc652356462b6/oslo_db/sqlalchemy/provision.py#L505

        The problem is that when you specify
        OS_TEST_DBAPI_ADMIN_CONNECTION it
        does end up creating the file, but then the logic above chooses
        a URL
        based on the random ident. So you can find an sqlite file in
        your tmp
        dir, it just won't be the one you asked for.

        It seems like a bug in the oslo.db logic, but the commit that
        added it
        was part of a much larger refactor so I'm not sure if it was
        intentional
        to ensure that no two tests used the same db.


    it is, the testr system runs tests in multiple subprocesses and I
    think neutron has it set to four.  if they all shared the same
    sqlite database file you'd have failed tests.


A potential improvement might be to replace
OS_TEST_DBAPI_ADMIN_CONNECTION with another environment variable which
could be used to provide a template for generating multiple unique
database names. That would make it a little more intuitive. But, I can
work with this for now.

perhaps we can allow some kind of tokenized syntax within the OS_TEST_DBAPI_ADMIN_CONNECTION variable itself. That env variable is already kind of a beast but at least there's just the one.





Car


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


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

Reply via email to