Merge lp:~flacoste/launchpad/bug-721324 into lp:launchpad
Proposed by
Francis J. Lacoste
Status: | Merged |
---|---|
Approved by: | Francis J. Lacoste |
Approved revision: | no longer in the source branch. |
Merged at revision: | 12419 |
Proposed branch: | lp:~flacoste/launchpad/bug-721324 |
Merge into: | lp:launchpad |
Diff against target: |
93 lines (+32/-2) 3 files modified
lib/canonical/config/schema-lazr.conf (+7/-0) lib/canonical/launchpad/webapp/haproxy.py (+10/-2) lib/canonical/launchpad/webapp/tests/test_haproxy.py (+15/-0) |
To merge this branch: | bzr merge lp:~flacoste/launchpad/bug-721324 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Brad Crittenden (community) | code | Approve | |
Benji York (community) | code* | Approve | |
Review via email: mp+50365@code.launchpad.net |
Commit message
[r=bac,benji][bug=721324] Made the haproxy going down status configurable.
Description of the change
This branch makes the result code to return when the app server is going down
configurable through a config variable.
That's for the +haproxy monitoring URL. We were returning 500, but it's
possible that 404 results in better behavior from HAProxy. We have to test to
make sure, so I'm making this result code configurable.
I didn't use a feature flag to control this because we don't want the +haproxy
URL to hit the database. (It gets a special DB policy and a
NullFeatureCont
Let me know if you have any questions.
To post a comment you must log in.
This branch looks good. Approved (but I'm doing mentored reviews so
Brad will review my review before you get a full approval.)
I only have two small (ignorable) thoughts about the branch:
The comment about the default value being 500 in the docstring could
easily get out of sync with reality. Maybe we should point to the place
the default is configured instead.
The second is that perhaps the test should use an invalid status code
instead. I worry that someone might introduce a bug that would cause a
404 to be generated when requesting /+haproxy instead of the configured
value and the test wouldn't fail. Perhaps the test should configure the
status to be 999 just to be sure we're getting back the status we
configured and not one someone else is setting.