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

ca: do not generate a ClusterID in the secondary #11367

Closed
dnephin opened this issue Oct 20, 2021 · 0 comments · Fixed by #11514
Closed

ca: do not generate a ClusterID in the secondary #11367

dnephin opened this issue Oct 20, 2021 · 0 comments · Fixed by #11514
Labels
theme/certificates Related to creating, distributing, and rotating certificates in Consul theme/connect Anything related to Consul Connect, Service Mesh, Side Car Proxies type/bug Feature does not function as expected

Comments

@dnephin
Copy link
Contributor

dnephin commented Oct 20, 2021 •
edited
Loading

This problem was noticed by the consul-k8s test suite. @freddygv and I found that:

  1. The "servers are upgraded" checks should return an error to indicate that initialization was not complete, and should be retried
  2. InitializeCAConfig should not be called in the secondary because it generates a ClusterID. We should initialize the config without generating a ClusterID.

The test failure may also be related to #10871 , because it appeared that a client agent may not have received the updated ClusterID after the secondary servers received the ClusterID from the primary.
@dnephin dnephin added type/bug Feature does not function as expected theme/connect Anything related to Consul Connect, Service Mesh, Side Car Proxies theme/certificates Related to creating, distributing, and rotating certificates in Consul labels Oct 20, 2021
@dnephin dnephin mentioned this issue Nov 5, 2021
Merged
2 tasks
@freddygv freddygv mentioned this issue Nov 9, 2021
Merged
freddygv added a commit that referenced this issue Nov 9, 2021
@freddygv
Merge pull request #11514 (#11539)
cbaa9ce 
Backport of #11514

---------

Fixes #11367

Previously `secondaryInitialize` would return nil in this case, which prevented the
deferred initialize from happening, and left the CA in an uninitialized state until a config
update or root rotation.

To fix this I extracted the common parts into the delegate implementation. However looking at this
again, it seems like the handling in secondaryUpdateRoots is impossible, because that function
should never be called before the secondary is initialized. I believe we can remove some of that
logic in a follow up.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
theme/certificates Related to creating, distributing, and rotating certificates in Consul theme/connect Anything related to Consul Connect, Service Mesh, Side Car Proxies type/bug Feature does not function as expected
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

ca: properly handle the case where the secondary initializes after the primary hashicorp/consul
1 participant
@dnephin