Keystone gate jobs unit tests live backends

Bug #1182092 reported by Adam Young
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Core Infrastructure
Triaged
Medium
Unassigned

Bug Description

Keystone has a body of unit tests that are part of the gate. However, there are run against the SQLite database, which means that many constraints go unchecked. In production, people run with MySQL, Postgresql, and various LDAP servers for the backend instead.

To run the tests tests, we would need a Database or OpenLDAP server set up the way that Devstack does.

For ldap, we need to then do the equivalent of ./run_test.sh _ldap_tls_livetest
For MySQL and Postgresql, we need to modify the file tests/backend_sql.conf (the mysql and postgresl lines are in there but commented out) and
 ./run_test.sh backend_sql (there might be others we want to add in the future, but this is a start)

These test will run much more slowly than the sql tests. Additionally, I think the mysql tests are broken of now, and should be only run in non-voting mode.

Revision history for this message
Jeremy Stanley (fungi) wrote :

Persistent resources like this can be somewhat problematic for unit test slaves, especially since they need to be preconfigured to allow the unpriviliged test user to interact with them (and at the same time prevent that user from being able to easily break them so that the next test run won't encounter false negatives due to previous tests breaking those resources). Also, if at all possible this needs to be designed in such a way that tests run in parallel won't step on each others' toes when possibly trying to interact with this shared resource simultaneously.

This is a much easier proposition if the tests are implemented in Tempest, since they'd have free run of the system to configure these services in whatever way they need (we just throw the server away after the job completes).

Changed in openstack-ci:
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
Clark Boylan (cboylan) wrote :

We have running MySQL and PostgreSQL servers on the unittest slaves with permissions configured to allow tests to run against the openstack_citest schema. Nova (and others now I believe) run their MySQL and PostgreSQL tests opportunistically if databases with this schema are available. I think that If keystone wants to do this type of testing it can do the same sort of thing. We had intended that this setup be generally useful so that projects other than Nova can use it. This also means we don't need to maintain a bunch of special cased tests.

Will this same sort of setup work for LDAP? If we make sure that there is a server running with some predefined parameters can the test suite check for the availability of this setup, make use of it if there, and clean it up post test?

To accomodate the tests run in parallel problem we are looking at allowing Nova to manage a DB schema per test worker. Individual test workers run serially so as long as they have their own schemas to play in this should avoid contention.

If the preexisting DB test infrastructure doesn't work for you let us know so that we can find something that is generally useful. Feedback very welcome.

Adam Young (ayoung)
description: updated
Revision history for this message
Adam Young (ayoung) wrote :

The current approach for SQL is to have a parallel user to the one that the Keystone server would use: db=keystone_test as opposed to db=keystone . That prevents it from conflicting with the Keystone server development, and would probably make sense for unit test runs as well.

LDAP could do the same kind of thing: have a setup that uses LDAP for the Identity backend along with one of the SQL backends for everything else. The unit tests could be run with a slightly different configuration: the devstack config sets up a subtree with

 url = ldap://localhost
user = cn=Manager,dc=openstack,dc=org
password = test
suffix = dc=openstack,dc=org

So

group_tree_dn = ou=UserGroups,dc=openstack,dc=org
user_tree_dn = ou=Users,dc=openstack,dc=org

For Testing we could do: suffix = dc=test,dc=openstack,dc=org
so

group_tree_dn = ou=UserGroups,dc=test,dc=openstack,dc=org
user_tree_dn = ou=Users,dc=test,dc=openstack,dc=org

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.