Closed sehz closed 4 years ago
It is using rustls
. However, we do want to preserve that capability. In order to do so we can put that under feature gate.
reason isahc
was used because it had good integration with rustls
. For native-tls
, we could consider switch to hyper
has good support
Right now I've been able to remove curl
, openssl-sys
, webpki
, rustls
, and fluvio-future
from the dependencies of k8-client
and continue building and testing successfully, even with --all-features
and --all-targets
. Right now the hyper
module is broken (i.e. re-enabling it immediately causes a build break) so it's hard to determine which dependencies would need to stick around and how to put them into feature flags. I think we should just remove the unused dependencies for now and add them back as needed in the future if and when we want hyper support.
put hyper
in the separate feature flag since it wasn't working previously
Done. Added feature flag for both rustls
and native_tls
. Use Hyper for Http Client
Here's what I've found after some research on this:
rustls
as a dependency in all of our crates. I found thatk8-client
was a big offender (being linked to by many of our other crates), and thatfluvio-future
was another.k8-client
was not actually usingrustls
at all, it can be removed without breaking any code.k8-client
has ahyper
module and anative
module to provide http clients. Currently, thehyper
module is commented-out in lib.rs, meaning that it is completely unused. It turns out thatrustls
is a dependency of this hyper client, so if we ever plan on re-activating that module, this is something we will have to take care of.rustls
fromk8-client
is not a problem, then our only dependency onrustls
andwebpki
are within thefluvio-future
crate when thetls
feature is activated. This will be my next point of research to see if we can use alternate dependencies to do whatevertls
needs to do.