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

Multiple hosts to Bunny #294

Open
bradrobertson opened this issue Sep 26, 2017 · 9 comments
Open

Multiple hosts to Bunny #294

bradrobertson opened this issue Sep 26, 2017 · 9 comments

Comments

@bradrobertson
Copy link

Right now the connection_params enforces a singular host option for the Bunny connection. In an HA world we'd like this to be an array of rabbitmq hosts. Would you be open to allowing the uri to have a comma separated host list, similar to how mongo handles clustering and instead pass hosts to Bunny?
This would be a backwards compatible change.

@michaelklishin
Copy link
Member

@bradrobertson why not add :hosts to it and pass it to Bunny? In fact, I think Hutch should expose all or at least all key connection-related options of Bunny.

@bradrobertson
Copy link
Author

Do you mean something like Hutch::Config[:mq_hosts] ? I'd be fine with that also. We'd just have to deal with the scenario of someone setting both as Bunny warns about that. Or we could just always pass in hosts to Bunny and either use Hutch::Config[:mq_hosts] or [ Hutch::Config[:mq_host] ]. Thoughts?

@michaelklishin
Copy link
Member

@bradrobertson I'd just pass both to Bunny and let it do what's right. Hutch's job is to provide an opinionated set of conventions and a CLI daemon, not reinvent Bunny's features.

@bradrobertson
Copy link
Author

Ya I understand what you're saying, but from what I can tell, Hutch always passes in host (if we use HUTCH_URI which we do exclusively) and Bunny uses host as a default (over hosts) so passing both in means we'd never take advantage of multiple hosts.

Simply passing in hosts instead gives us the best of both worlds.

@michaelklishin
Copy link
Member

@bradrobertson hm, and :host takes precedence. It doesn't have to be that way, if :hosts is set in the config we can assume the user wants it to be used. Using both options makes little sense.

@bradrobertson
Copy link
Author

Sure... Ok so the story is:

  1. Add a Hutch::Config[:mq_hosts] option, maps to the bunny hosts config option
  2. Prefer mq_hosts over mq_host if both are set

Questions:

  1. How do you want sanitized_uri dealt with. It seems to just be presentational, should it honour the same as above (prefer hosts over host) and maybe just comma separate hosts in the uri string?
  2. How does mq_api_host factor in here? I'm not actually sure what the api is used for in Hutch. Does it also need to support a rabbitmq cluster?

@michaelklishin
Copy link
Member

While Bunny supports its own ENV variable for URI connections IIRC (I have never advertised this feature and it was added for compatibility), Hutch's one is only managed by Hutch, so comma separating can be accomplished.

"mq_api_host" is RabbitMQ HTTP API. I suspect that Ruby HTTP API client used by Hutch. Hutch uses it to infer some information about the topology.

@michaelklishin
Copy link
Member

Err, by "can be accomplished" I mean "can be acceptable". I have no objections to that.

@michaelklishin
Copy link
Member

Any updates on this? It is possible to pass in a connection as a workaround but this idea seems reasonable to me.

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

No branches or pull requests

2 participants