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.

Sign up for GitHub

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

Jump to bottom

Confusing error when configuring encryption #718

Closed
blalor opened this issue Feb 20, 2015 · 3 comments
Closed

Confusing error when configuring encryption #718

blalor opened this issue Feb 20, 2015 · 3 comments

Comments

@blalor
Copy link
Contributor

blalor commented Feb 20, 2015

I started the agent and server with -encrypt. Then I added installed and enabled a new key. Finally I deleted the old key (the one initially used with -encrypt). Upon restarting the agent, I see:

==> WARNING: LAN keyring exists but -encrypt given, ignoring

Obviously the LAN keyring is taking precedence over the one given with -encrypt, but the warning message is misleading.
@ryanuber
Copy link
Member

@blalor ah, re-reading the message now it does sound a little ambiguous (what is it ignoring?). I'll clarify.

@ryanuber
Copy link
Member

@blalor the message should now read:

WARNING: LAN keyring exists but -encrypt given, using keyring

Thanks for the report!

@blalor
Copy link
Contributor Author

blalor commented Feb 20, 2015

👍

@blalor blalor mentioned this issue Feb 20, 2015
Closed
duckhan pushed a commit to duckhan/consul that referenced this issue Oct 24, 2021
@ndhanushkodi
Log envoy config for mesh gateways on test failures (hashicorp#718)
146833a 
If the mesh gateway tests fail, the acceptance tests will now write two
files <PODNAME>-envoy-configdump.json and <PODNAME>envoy-clusters.json
which will have information from the envoy admin /config_dump endpoint
and /clusters endpoint.

Currently we write the outputs of `kubectl logs POD` and `kubectl describe
POD` for the acceptance tests, but while debugging EKS acceptance test
failures, it was hard to know from our existing logs whether the mesh
gateway itself is unreachable or if the consul servers behind it are
unhealthy. We'd be able to tell this from looking at the envoy config
dump and cluster config to see what envoy's view of the consul servers
are.
duckhan pushed a commit to duckhan/consul that referenced this issue Oct 24, 2021
@lkysow
Bump default Consul version to 1.10.2 (hashicorp#718)
10328ec 
- fix tests that were failing due to a change in how the
DestinationUpstream field is set in Consul OSS vs Enterprise.
- set use_streaming_backend to false for Consul clients because
streaming is not currently supported with mesh gateway federation
@ekmixon ekmixon mentioned this issue Nov 28, 2023
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@blalor @ryanuber