-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Secrets Reencrypt command throws fatal error client timing out when there are 1000 basic secrets to reencrypt #11384
Comments
Yeah this is just a cosmetic thing - as you noted the re-encrypt does in fact finish. Rather than having the client make a single request that doesn't return until the re-encrypt is done, it should probably make 1 request to initiate the re-encrypt operation. That request should return immediately, and then the client can poll with additional status requests until the operation is complete. cc @dereknola |
That's not how reencrypt works right now. We don't wait for it to finish. That's why we print The request trigger a annotation to be written on the node, which the k3s secrets-encryption controller watches. The response header is sent immediately after the annotation is written on the server node. |
Okay, when #10612 got merged, the logic around http replies got muddled. We should not be waiting for that function to finish, we should just move on now. |
Not sure how we didn't hit this till now, but should be a simple fix. Since its a cosmetic, lets just target December. |
Closing based on release-1.31 results: #11437 |
Build details:
Branch: release-1.31
Commit ID: e99a668
Environment Details
Infrastructure
Node(s) CPU architecture, OS, and Version:
Cluster Configuration:
Describe the bug:
Etcd Config.yaml:
Control Plane Config.yaml:
Testing Steps to Reproduce:
Expected behavior:
Secrets encryption operations should be successful
Actual behavior:
Reencrypt operation times out with fatal error.
The status shows reencrypt finished though. (Output shown - Before reboot of all nodes. So hashes dont match yet)
From the journal logs - it looks like the reencrypt action is actually successful - and this could be a client monitor that times out.
The text was updated successfully, but these errors were encountered: