Skip to content
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

Merged
merged 17 commits into from
Jul 23, 2015
Merged

Merge the forks #130

merged 17 commits into from
Jul 23, 2015

Conversation

jolynch
Copy link
Collaborator

@jolynch jolynch commented Jul 22, 2015

I believe that this takes your feedback from #115, adds some documentation of the features we added.

Major changes in this fork:

  • Service watchers that use the same zookeeper hosts will share one underlying zookeeper connection
  • Allow output of registrations to json files on the filesystem instead of just HAProxy
  • Allow rate limiting HAProxy restarts more aggressively than socket reconfigures
  • Add a cache of recently seen backends that are put in "disabled" and can then be enabled over the socket without a restart.

jnb and others added 15 commits July 21, 2015 17:16
* 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`.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh thank god, finally!

@igor47
Copy link
Collaborator

igor47 commented Jul 22, 2015

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)

@jolynch
Copy link
Collaborator Author

jolynch commented Jul 23, 2015

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?

@schleyfox
Copy link
Contributor

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",
Copy link
Contributor

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?

Copy link
Collaborator

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

Copy link
Collaborator Author

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.

@jtai
Copy link
Contributor

jtai commented Jul 23, 2015

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.
@igor47
Copy link
Collaborator

igor47 commented Jul 23, 2015

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

jnb added a commit that referenced this pull request Jul 23, 2015
@jnb jnb merged commit 3e36e88 into airbnb:master Jul 23, 2015
@jolynch jolynch mentioned this pull request Jul 23, 2015
@jolynch
Copy link
Collaborator Author

jolynch commented Jul 23, 2015

We're going to start dogfooding 3e36e88 and then when you release we'll switch to that.

@igor47
Copy link
Collaborator

igor47 commented Jul 24, 2015

ok i released v0.12.1; i'm going to start trying it here as well

@igor47
Copy link
Collaborator

igor47 commented Jul 28, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants