Open eramnes opened 3 years ago
Files identified in the description:
If these files are inaccurate, please update the component name
section of the description or use the !component
bot command.
!component =plugins/lookup/etcd3.py
Files identified in the description:
If these files are inaccurate, please update the component name
section of the description or use the !component
bot command.
This is the expected behavior of the etcd3
library this plugin uses. (See here)
In order for the client to use a HTTPS connection ca_cert
must be provided with cert_cert
and cert_key
optionally included.
Maybe just a doc update is appropriate for this issue.
cc @eric-belhomme click here for bot help
SUMMARY
When using an etcd3 cluster that is configured to use HTTPS, the etcd3 lookup provider appears to be unable to connect to it. Specifying an endpoint of
"https://<etcd3_host>:<port>"
seems to strip the "https://" from the connection string, and using a host of"https://<etcd3_host>"
seems to try to perform a DNS lookup that includes the "https://".ISSUE TYPE
COMPONENT NAME
etcd3 lookup provider
ANSIBLE VERSION
CONFIGURATION
OS / ENVIRONMENT
Operating System: Red Hat Enterprise Linux 8.3 (Ootpa) CPE OS Name: cpe:/o:redhat:enterprise_linux:8.3:GA Kernel: Linux 4.18.0-240.10.1.el8_3.x86_64 Architecture: x86-64
$ pip3 show etcd3 Name: etcd3 Version: 0.12.0
$ pip3 show grpcio Name: grpcio Version: 1.35.0
I have verified that the machine Ansible runs on is able to successfully connect to the etcd3 cluster:
The etcd3 cluster appears to be healthy and listening on HTTPS:
STEPS TO REPRODUCE
EXPECTED RESULTS
The etcd3 lookup completes successfully, and returns the value assigned to the requested key
ACTUAL RESULTS
When run with the "endpoint" variable set:
On the etcd3 server, you can see that the lookup tried to connect, but appears to have used HTTP instead of HTTPS:
When run with the "host" variable set:
It appears to me from the output that it's attempting the DNS lookup for the host, but including the "https://" instead of just looking at the actual FQDN.
I had to try to sanitize some of the playbook names. I think I got them all, but if anything looks inconsistent in the workflow it's probably my fault.
Thanks!