Merge lp:~stub/launchpad/branch-rewrite into lp:launchpad
Proposed by
Stuart Bishop
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | Stuart Bishop | ||||
Approved revision: | no longer in the source branch. | ||||
Merged at revision: | 13863 | ||||
Proposed branch: | lp:~stub/launchpad/branch-rewrite | ||||
Merge into: | lp:launchpad | ||||
Prerequisite: | lp:~stub/launchpad/pgbouncer-fixture-noca | ||||
Diff against target: |
284 lines (+132/-12) 6 files modified
lib/canonical/config/tests/test_database_config.py (+2/-1) lib/canonical/launchpad/doc/canonical-config.txt (+2/-1) lib/lp/codehosting/tests/test_rewrite.py (+89/-7) lib/lp/testing/__init__.py (+24/-0) lib/lp/testing/tests/test_pgsql.py (+1/-1) scripts/branch-rewrite.py (+14/-2) |
||||
To merge this branch: | bzr merge lp:~stub/launchpad/branch-rewrite | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Jeroen T. Vermeulen (community) | Approve | ||
Review via email: mp+73563@code.launchpad.net |
This proposal supersedes a proposal from 2011-08-29.
Commit message
[r=jtv][bug=836662] Make branch-rewrite.py survive database outages
Description of the change
= Summary =
branch-rewrite.py does not reconnect after a database outage.
== Proposed fix ==
Make it reconnect after a database outage.
To post a comment you must log in.
Hi Stuart,
Generally good, but I have a few things that look worth fixing.
=== modified file 'lib/lp/ codehosting/ tests/test_ rewrite. py' codehosting/ tests/test_ rewrite. py 2011-08-12 11:37:08 +0000 codehosting/ tests/test_ rewrite. py 2011-08-29 20:15:59 +0000
--- lib/lp/
+++ lib/lp/
@@ -177,7 +181,8 @@
transaction. commit( )
rewriter. rewriteLine( '/' + branch.unique_name + '/.bzr/README')
rewriter. rewriteLine( '/' + branch.unique_name + '/.bzr/README') output_ lines = self.getLoggerO utput(rewriter) .strip( ).split( '\n') output_ lines = self.getLoggerO utput( .strip( ).split( '\n')
- logging_
+ logging_
+ rewriter)
Cleaning out lint, I see. Thanks.
@@ -274,3 +280,62 @@
self. assertEqual( '', err)
self. assertEqual( expected_ lines, output_lines) terScriptHandle sDisconnects( TestCaseWithFac tory): Layer hRewriterScript HandlesDisconne cts, self).setUp() (self.pgbouncer .cleanUp) setUp()
# The script produces logging output, but not to stderr.
+
+
+class TestBranchRewri
+ """Ensure branch-rewrite.py survives fastdowntime deploys."""
+ layer = LaunchpadScript
+
+ def setUp(self):
+ super(TestBranc
+ self.pgbouncer = PGBouncerFixture()
+ self.addCleanup
+ self.pgbouncer.
Couldn't those last three lines be replaced with a simple
self.pgbouncer = self.useFixture (PGBouncerFixtu re())
?
In fact I'm not even sure it's worth a setUp with the super() dance, and carrying self.pgbouncer from setUp to the tests.
+ def spawn(self): rewrite. py') s.PIPE, stdout= subprocess. PIPE, subprocess. PIPE, bufsize=0)
+ script_file = os.path.join(
+ config.root, 'scripts', 'branch-
+
+ self.rewriter_proc = subprocess.Popen(
+ [script_file], stdin=subproces
+ stderr=
Again, is it worth keeping self.rewriter_proc on the test class? It just hides state. Why not make it a return value?
Moreover, is this process guaranteed to clean itself up? If not, then please ensure that it is. For instance, you could add something like "self.addCleanu p(kill, rewriter_proc)" to spawn().
+ def request(self, query): proc.stdin. write(query + '\n') proc.stdout. readline( ).rstrip( '\n')
+ self.rewriter_
+ return self.rewriter_
Do we know that the readline() will never hang under reasonable circumstances?
+ def test_disconnect (self):
+ self.spawn()
Sure "disconnect" is something that happens in this test, but is that one word really a good description of what you're testing here? Would it help to say something with "reconnects"?
+ # Everything should be working, and we get valid output. '/foo') , out
+ out = self.request('foo')
+ assert out.endswith(
Why use assert here? Normally you'd say self.assertEnds With(out, '/foo').
+ self.pgbouncer. stop()
+
+ # Now with pgbouncer down, we should get NULL messages and
+ # stderr spam, and this keeps happening. We test more than
+ # once to ensure that we will keep trying to reconnect even
+ # after several failures.
+ for count in range(5):
+ out = self.request('foo')
Is this race-free? I don't know ...