I would like to suppress the urllib3 warnings about insecure SSL usage. However, none of the usual means work for me. even PYTHONWARNINGS=ignore which is more of a blanket statement than I'd like to make continues to allow the warnings through.
What's the way to suppress the warnings?
Urllib3 went to great lengths to prevent end-users from hiding the message. Are you using self-signed certificates? Or is it a hostname mismatch because you're behind a proxy or something? It isn't too big a deal to use your self-signed CA with Curator, and then those messages go away, but I can't do anything about hostname mismatches 
I'm connecting via SSL but not using any cert. urllib3 does document how to silence them. Is there a reason those methods don't work for curator?
I'd really prefer not to bother with the whole self-signed cert thing if I can.
The document you referenced does, indeed, show how to silence it:
Making unverified HTTPS requests is strongly discouraged, however, if you understand the risks and wish to disable these warnings, you can use
disable_warnings():>>> import urllib3 >>> urllib3.disable_warnings()
You would have to edit the elasticsearch python module itself to do this. I do not think that the environment variable of PYTHONGWARNINGS=ignore or the -W flag will do anything with Curator as installed as it is typically installed, since that flag appears to be related to the launching with python script_name.py (the interpreter), and Curator runs as an endpoint, which would obviate that.
Technically, the warning is correct. If you do not allow urllib3 to validate the certificate, it is an insecure (unverified) connection, and as an admin, I prefer upstream libraries I use (like urllib3) to inform me of such things. Silencing such errors is a bit like cutting the wire under the dash of a car that lights a warning light. Preventing the light from illuminating doesn't actually mean there's no warning condition.
as an admin, I prefer upstream libraries I use (like urllib3) to inform me of such things. Silencing such errors is a bit like cutting the wire under the dash of a car that lights a warning light. Preventing the light from illuminating doesn't actually mean there's no warning condition.
Very true. In this case, as the doc points out, I understand the risks and would really just like the light not to blink. 
Curator runs as an endpoint
I'm not sure what you mean by this. Do you mean it runs as an HTTP service? I was planning on having it executing from a Jenkins job which so far in my testing seems to be the right thing to do but maybe not? I have seen the notion of running in the cluster mentioned several times in the docs, but then the docs also say it's a CLI utility, not a plugin, so I'm not sure how to reconcile the two.
Sorry, I used the wrong word. It should read entry_point rather than endpoint.
A python entry_point is a wrapper script that launches the program.
As such, it's more like running a bash script with the #!/bin/bash at the top, rather than the python script_name.py execution that the -W flag or the environment variable requires.
And as far as running from Jenkins goes, Curator doesn't care where it's launched from, it only needs client access to a node in the cluster. It doesn't have to reside in the cluster, though some choose for it to do so. That's what that's in the documentation. Some people using utilities like Puppet or Chef push identical configurations to each node, including Curator. They need the "master_only" flag so that even though it's called on every node, it only executes on the elected master node.
Got it. That all makes sense.
Thanks for your help!
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
© 2020. All Rights Reserved - Elasticsearch
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant logo are trademarks of the Apache Software Foundation in the United States and/or other countries.