-
Notifications
You must be signed in to change notification settings - Fork 251
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge the forks #130
Merge the forks #130
Conversation
* This option defaults to true: if there are no default servers and a watcher reports no backends, then use the previous backends that we already know about. * Factor out code that updates '@backends' into the watcher base class.
If the configuration specifies a file_output key, synapse will manifest and update registrations on the filesystem in an atomic way. This is useful for applications that do not wish to communicate with service backends via haproxy
Note that at this time only the Yelp fork of haproxy has support for redispatching on every retry.
This reverts commit 136d1fe.
We can allow socket updates to go through any time that the config was updated, but restarts must be rate limited for stability
We are experiencing some very slow updates in production and I think it may be due to the connection pooling, try :per_callback threading to see if that helps. Also fixes default values for do_writes, do_reloads, do_socket
This fixes a bug where we could have a session expiry but not fail pings because the pooling code would not actually tear down the connection
@@ -198,6 +198,19 @@ If you do not list any default servers, no proxy will be created. The | |||
`default_servers` will also be used in addition to discovered servers if the | |||
`keep_default_servers` option is set. | |||
|
|||
If you do not list any `default_servers`, and all backends for a service | |||
disappear then the previous known backends will be used. Disable this behavior | |||
by unsetting `use_previous_backends`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh thank god, finally!
looks pretty good overall. i left a few questions in a few places. i also think the test coverage is a little light, especially around zk connection pooling and all of the new haproxy functionality. i think a few additional airbnb peeps from our production infrastructure team would like to take a look. ping @schleyfox @jtai thanks for doing this, i'm excited about all of the great new functionality (especially connection pooling, the disabling of the keep-backends misfeature, and the haproxy state file so you can continue to see the disabled backends) |
Yea, the connection pooling and haproxy cache code was sorta done under P0 pressure (site was actively degraded kind of P0), so we didn't write too many tests heh. Do you think the lack of test coverage blocks merge or is it something that I can work on in separate PRs against this repo after the fork is gone? |
I gave it a skim and it seems pretty reasonable to me. I'm excited. |
Adds a comment about when we write out the file output and restored random backend ordering.
@@ -43,6 +45,7 @@ class Haproxy | |||
"option abortonclose", | |||
"option accept-invalid-http-response", | |||
"option allbackups", | |||
"option allredisp", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this cause problems for standard builds of haproxy?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no this is just a list of valid options so we can validate the in-synapse haproxy config. we already have a few options here which won't work with haproxy < 1.5; the symptoms if you use unsupported options is that synapse will start, but it's every attempt to restart haproxy will fail
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both my patches were accepted into 1.6, and Willy just released 1.6-dev3 so we're almost off our fork! Once we upgrade to 1.6 I can go through and re-sync this list with what haproxy accepts. There might be some backwards incompatible changes in 1.6 from 1.5 (only one I have ran into was listen no longer accepts ports in the listen line) so that should be a fun exercise.
These improvements are awesome! Thank you! |
Added documentation of the state_file cache options as well as a few comments. Also fixed some error messages to be more clear.
okay i think this is ready to merge. once that's done, i'll bump the version and release a build, and we can start trying to run it in airbnbland |
We're going to start dogfooding 3e36e88 and then when you release we'll switch to that. |
ok i released v0.12.1; i'm going to start trying it here as well |
my smoke testing went well, and now i'm allowing synapse v0.12.1 to propagate through our infrastructure; i'm going to tackle airbnb/nerve#71 now |
I believe that this takes your feedback from #115, adds some documentation of the features we added.
Major changes in this fork: