I'm not able to dupe this after repeated attempts in a non-parallel lxc lucid container. Intermittent issues often signal timing issues, and the possibility that jumps out to me is that the bouncer isn't quite started yet. In pgbouncer.fixture.PGBouncerFixture.start, the code waits to see the bouncer's pid. Perhaps the presence of the bouncer's pid is not sufficient to indicate that the bouncer is ready. In that case, a proper fix might be to change bouncer code so that the pid is in fact a reliable indicator; or to change the fixture to look for some other more reliable signal. A more temporary fix (and/or an easier indication that this hypothesis has merit) might be to retry the assertion in this test a few time with a time.sleep(0.5) between each attempt. Working with a pgbouncer dev might be helpful.

(Additionally the format string uses a Python 2.7 feature, leading to the error seen in the traceback. "bouncer did not come up after {} attempts.".format(retries) needs to be something like "bouncer did not come up after {count} attempts.".format(count=retries) in 2.6.)

Right now, in the pgbouncer fixture, we are saying that we have finished with the "start" method as soon as there is a pgbouncer subprocess and we can poll it. There's no guarantee that this will mean that pgbouncer is actually "open for business". There might or might not be a guarantee that Launchpad is ready to recognize that pgbouncer has returned.

Still not resolved. Failed again today with Benji's patch. Benji's patch shows that pgbouncer is ready, but not that LP is ready. I still think we should re-add explicitly what is in comment 7. If that fails, after five seconds of retries and the checks Benji added, I'd say we need to look elsewhere for why we keep getting this failure.