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

Consider supporting custom ssl certificates configuration for elasticsearch client #39

Open
erichs opened this issue Jul 16, 2015 · 2 comments

Comments

@erichs
Copy link

erichs commented Jul 16, 2015

It would be really great to support the transport_options hash parameter for the Elasticsearch::Client initialization, to specify a custom SSL cert for https:// urls.

See this section of the Elasticsearch README for example usage.

Not sure what your preferred method of passing this configuration data into the redis-stat server is, @junegunn.

It feels like adding another CLI flag for this option would be clunky, and you don't have any precedent for a config file. What are your thoughts here?

I'd be happy to help with a PR, or could fork if you think this change isn't generally useful.

Thanks for such a great tool!

@junegunn
Copy link
Owner

Hi, actually adding support for ElasticSearch was not my idea, and due to my lack of good understanding of ES, the feature has not been systematically tested and I'm not really sure if the current implementation follows the best practice. So if you have any feedback on the part, feel free to let me know.

So anyway, looks like we have three options:

  1. Another CLI flag
    1. We're current packing stuff into a single --es flag, adding another doesn't really feel nice
    2. Short-sighted if we're going to have to add more of such flags
  2. Environment variable (e.g. ES_CA_PATH)
    1. Easier to implement, and to extend in the future
    2. It's the first env var ever used, so it's inconsistent
  3. External config file
    1. The ultimate solution
    2. Most likely overkill

@erichs
Copy link
Author

erichs commented Jul 20, 2015

Of those options, an ENV var gets my vote!

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