Hi Nejc, Apologies for the delay in responding, I'm just getting to grips with Tempest myself.
So the problem here is nothing to do with whether the tenant exists in keystone, in fact creating an alarm with a completely fictitious project_id will work just fine in general. Rather it appears to be an artifact of how the alarm creation logic was added to the sqlalchemy driver in such a way as to rely on sqlalchemy session merge to create the corresponding entries in the project & user tables[1]. Then subsequently a *later* migration[2] was added to assert foreign key constraints for those project & user IDs. I'm no sqlalchemy expert, but I don't think session merge is a reliable way to ensure creation of the corresponding rows in the related tables in order to satisfy the foreign key constraints. I've filed a bug[3] and will propose a patch to explicitly create the project & user IDs. This should address the intermittent failure you're seeing. Cheers, Eoghan [1] https://github.com/openstack/ceilometer/commit/2c84007b [2] https://github.com/openstack/ceilometer/commit/fa6f9807 [3] https://bugs.launchpad.net/ceilometer/+bug/1255107 ----- Original Message ----- > Hey, > > still trying to get https://review.openstack.org/#/c/39237/ through the gate > :) > > As per David Kranz's request, I am now handling client isolation, but about > 50% of the time the tests fail because of an integrity error, see > http://logs.openstack.org/37/39237/13/check/check-tempest-devstack-vm-full/53c0fc1/console.html.gz > . > > The tenant does get created in keystone and the ids do match up, so I have no > clue what is causing this. Any ideas? > > Cheers, > Nejc > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
