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

janus_cli: kube uses rustls rather than OpenSSL even in debug builds #327

Closed
branlwyd opened this issue Jul 22, 2022 · 2 comments · Fixed by #345
Closed

janus_cli: kube uses rustls rather than OpenSSL even in debug builds #327

branlwyd opened this issue Jul 22, 2022 · 2 comments · Fixed by #345

Comments

@branlwyd
Copy link
Member

branlwyd commented Jul 22, 2022

The intended behavior is that debug builds will use OpenSSL, while release builds will use rustls. This is to work around kube-rs/kube#153 -- rustls currently can't connect to a Kubernetes cluster through an IP address. The linked issue does not affect "in-cluster" usage, so using rustls for release builds is acceptable.

This worked at time of commit in #314 (should be double-checked), we can bisect from there to find where the breakage occured. Until this issue is resolved, local users of janus_cli need to modify the janus_server/Cargo.toml to switch the default feature list from "kube-rustls" to "kube-openssl".

@branlwyd branlwyd changed the title janus_cli: kube uses OpenSSL rather than rustls even in release builds janus_cli: kube uses rustls rather than OpenSSL even in debug builds Jul 22, 2022
@branlwyd
Copy link
Member Author

(argh, the issue title was backwards)

@divergentdave
Copy link
Contributor

I checked out 7beee2a, ran some debug builds for both the single binary target and the whole workspace, and the rustc invocations all include --cfg 'feature="kube-rustls"' when building targets in janus_server. (The same is true at the tip of main)

I don't think that we can get anything from default-features = false in janus_server's dev-dependency on itself, because (a) the set of features that are enabled for a crate is the union of all features required by its dependents, so we would be taking the union of the default feature set, ["kube-rustls"] with ["kube-openssl", "test-util"], and (b) development dependencies are only considered when building tests, examples and benchmarks, not binary targets, and the choice of release or dev profile is orthogonal to development dependencies.

I think it would make sense to drop kube-openssl from the self-dev-dependency, and document that when using Kind, the tool should be run with cargo run --bin janus_cli --no-default-features --features kube-openssl -- <SUBCOMMAND> ....

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

Successfully merging a pull request may close this issue.

2 participants