-
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
Create an option to stop ignoring weights. By default weights will still be ignored. #174
base: master
Are you sure you want to change the base?
Changes from 2 commits
06c8433
d5ea7b0
c3bcd29
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -535,6 +535,7 @@ def initialize(opts) | |
@opts['do_writes'] = true unless @opts.key?('do_writes') | ||
@opts['do_socket'] = true unless @opts.key?('do_socket') | ||
@opts['do_reloads'] = true unless @opts.key?('do_reloads') | ||
@opts['ignore_weights'] = true unless @opts.key?('ignore_weights') | ||
|
||
# how to restart haproxy | ||
@restart_interval = @opts.fetch('restart_interval', 2).to_i | ||
|
@@ -742,6 +743,14 @@ def generate_backend_stanza(watcher, config) | |
b = "\tserver #{backend_name} #{backend['host']}:#{backend['port']}" | ||
b = "#{b} cookie #{backend_name}" unless config.include?('mode tcp') | ||
b = "#{b} #{watcher.haproxy['server_options']}" if watcher.haproxy['server_options'] | ||
if !@opts['ignore_weights'] && backend.has_key?('weight') | ||
# Check if server_options already contains weight, is so log a warning | ||
if watcher.haproxy['server_options'].include? 'weight' | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the backend (server) provided There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @jolynch, that's a good point. To reduce the number of iteration for this PR, could you suggest what message you'd like to see when haproxy_server_options also includes weight? |
||
log.info "synapse: weight is defined by server_options and by nerve" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. log.warn (nit) |
||
end | ||
weight = backend['weight'].to_i | ||
b = "#{b} weight #{weight}" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So I believe that HAProxy will use the last weight provided. If that's true I think this should probably slot this in between the HAProxy backend There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. or maybe we should bail of server options also contains weight? i don't have a strong feeling as to what the precedence order should be... at least printing a warning to logs when there are contradictory options seems like a good idea. this is probably indicating that it's time to refactor this function, it's getting pretty big. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yea, I noted a similar concern about complexity in #171. I'm not sure if these PRs are the right place for that though or if we should refactor it once they're merged. I agree printing a warning is useful, but I don't think we should bail out as I can understand use cases where someone might want to set some combination as a fallback scheme. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
end | ||
b = "#{b} #{backend['haproxy_server_options']}" if backend['haproxy_server_options'] | ||
b = "#{b} disabled" unless backend['enabled'] | ||
b } | ||
|
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.
Do you have strong feelings about this being an option? I'd prefer for folks to just not register weights unless they want them reflected in HAProxy.
Yea I know the other PR did it, but I think it's maybe not the best option...
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.
i am also not a big fan of this option
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.
This is mainly for safety so people can rollout a new version without worrying about breaking something. I'm also not a fan of this option but it's kind of necessary unless you roll this into a major release.
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.
ignore_weights
doesn't seem very useful as a setting and it is confusing that the default is shipped in a disabled state. There isn't a similar disable switch forhaproxy_server_options
and that's way more powerful than the weights setting (rhetorical question: why not just sethaproxy_server_options
toweight 10
?).If the main concern is a breaking API change, then I would suggest bumping to a new major release for the next version. What do you all think?
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.
@minkovich I'm fine with us cutting a new minor (aka major in 0.X parlance) version if that's the concern. I think if folks are registering a
weight
they should expect to have it reflected in the load balancers.@scarletmeow Weight is separate for a few reasons. The first is because it was merged before I came up with
haproxy_server_options
back when the plan was to merge all the things as top level keys. The second is because it can be dynamically updated over the stats socket making it much more useful for dynamically balancing load while most options that occur inhaproxy_server_options
(e.g. healthcheck, backup status. etc ...) cannot. The third is because it is frontend agnostic, weight is a common concept in all load balancers that I'm aware of.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.
@jolynch @igor47 @scarletmeow I'm going to wipe out the option to ignore weights. It's going to simplify the code a lot. I'd just bold it in the announcement when you cut the next release. :)