Add support for https endpoints

[davissp14]

https://github.com/kragniz/python-etcd3/blob/master/etcd3/client.py#L108

As of right now if no certs are provided it's assumed it's an insecure connection. We should be setting the default grpc channel credentials in the event https is present without certs.

Example:
https://github.com/davissp14/etcdv3-ruby/blob/master/lib/etcdv3/connection.rb#L41-L47

[davissp14]

Looks like this may be what we want here:
https://grpc.io/grpc/python/grpc.html#grpc.ssl_channel_credentials

The PEM-encoded root certificates as a byte string, or None to retrieve them from a default location chosen by gRPC runtime.

Specifying None should pick up the default root certificate.

[mattzque]

seems like the library is not actively developed anymore?
I've got the same issue, simple fix would be something like this: https://github.com/mattzque/python-etcd3/commit/36d5e3504b012b7e1794e34e1b460f39c5e8d0ca
and then passing ca_cert=True, that will then specify None to ssl_channel_credentials

Multiple hostnames would be another critical feature, but that also seems to have stalled #106

[almeida-raphael]

@mattzque I agree with you. I really need #106 and it seems to have stalled. Is there anyone who can inform if the lib is actively developed or not? If it's active, an ETA for #106 changes would be nice. I'm using this lib for something critical, and if it's not being actively developed I have to choose another one.

[kragniz]

@Raphael-C-Almeida would you like to submit a PR for the changes you require?

[almeida-raphael]

@Raphael-C-Almeida would you like to submit a PR for the changes you require?

The changes are already being developed by people far more competent on grpc and etcd than myself. I'm still learning the lib internals and grpc and if i came up with something nice i will surely submit a PR =]. I really didn't mean to be harsh.

I saw that the #106 was moving and stopped on july with unsuccessful Travis build and a merge conflict. And since it's something really useful I'm interested on it's dev stage. I'm not criticizing the lib nor the good will of the contributors, on contrary, it's the best etcd3 lib I could find.

My question above was really to know about the current dev state, if it's receiving only maintenance or if it's receiving new features.

Please forgive me if my last message sounded like I'm demanding something, that wasn't really my intention.

[kragniz]

I think #106 is pretty stalled, it'd be great if you maybe could pick it up and try to get it into a mergable state.

I'm personally not using this library in production at the moment, so it's only receiving basic maintenance from me. New features are welcome, though, and I'm open to adding new maintainers.