Confusing error when configuring encryption #718
Comments
|
@blalor ah, re-reading the message now it does sound a little ambiguous (what is it ignoring?). I'll clarify. |
|
@blalor the message should now read: Thanks for the report! |
|
👍 |
duckhan
pushed a commit
to duckhan/consul
that referenced
this issue
Oct 24, 2021
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
- 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:Obviously the LAN keyring is taking precedence over the one given with
-encrypt, but the warning message is misleading.The text was updated successfully, but these errors were encountered: