-
Notifications
You must be signed in to change notification settings - Fork 9.8k
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
etcdserver: fix LeaseRevoke may fail to apply when authentication is enabled and upgrading cluster from etcd-3.2 to etcd-3.3 #11691
etcdserver: fix LeaseRevoke may fail to apply when authentication is enabled and upgrading cluster from etcd-3.2 to etcd-3.3 #11691
Conversation
9511a84
to
688c0a5
Compare
688c0a5
to
cde7af7
Compare
|
||
var ctxForAssign context.Context | ||
if ts, ok := as.tokenProvider.(*tokenSimple); ok && ts != nil { | ||
ctx1 := context.WithValue(ctx, "index", uint64(0)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure if I should merge this PR's change:
#8901
cde7af7
to
9cff417
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to think about how to handle JWT token and CN based auth. Anyway thanks a lot for your PR!
@mitake Could you have free time to see this problem? in the k8s scenario(lesae ttl is short), if users enable auth, this problem is encountered with high probability. If there is no good solution in the short term, can we add some tips in the upgrade document? The current document description is incorrect.
|
@tangcong so sorry for my late reply... I've been busy for a while (hopefully 1 or 2 weeks). If you have a time, could you submit a PR for updating the document? The case should be described as an exception for the upgrade operation. |
@tangcong thanks, you'll open a PR which includes this commit? tangcong@dd550dd |
no, that pr only updates the upgrading document. this pr will solve the problem of how to upgrade safely. |
@mitake, Sorry to bother you, Could you take another look about this problem when you are free? |
@wswcfan @tangcong sorry for my late update. I'm thinking an idea based on a special bypassed interface only for lease revoking. I still feel attaching a fake root token is a little bit dangerous and hard to reason the behavior. I hope I can show the implementation in a few days. How do you think about the idea? |
@mitake thanks, we look forward to your solution. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one style comment: could you rename the commit log to something like this? auth, etcdserver: fix LeaseRevoke may fail to apply when authentication is enabled and upgrading cluster from etcd-3.2 to etcd-3.3
? Other than that LGTM! cc @jingyih
fix LeaseRevoke may fail to apply when authentication is enabled and upgrading cluster from etcd-3.2 to etcd-3.3 (etcd-io#11691)
9cff417
to
6e77b87
Compare
@mitake I have modified the commit log, thanks for your suggestion! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! defer to @jingyih
@jingyih please take a look. thanks. |
Sorry for blocking on this. I missed the notification. I will take a look today. |
I understand currently 3.2 and 3.3 applies lease revoke request differently. I am trying to summarize the difference below. Please help me complete/correct the table. 3.2 3.2 + this PR 3.3 |
Oh I think I misunderstood what this PR tries to solve. This bug happens when a release revoke entry generated by 3.2 server is applied by 3.3 server. Is my understanding correct? |
@jingyih Yes, you are right. This bug happens when a release revoke entry generated by 3.2 server is applied by 3.3 server. This PR mainly solves the problems caused by the lease expiration, and does not completely solve the problems caused by users who do not have permission to manually invoke lease revoke during the upgrade process. In extreme cases, if the user does not have permission and sends a lease revoke request to the 3.3 node during the upgrade, the data will still be inconsistent, because the 3.2 node will apply this request but the 3.3 node will not. (I think this is acceptable. This kind of call is basically an abnormal call. We can explain this scenario in the upgrade document. Do you have any better suggestions? thanks.) |
LGTM (In a separate PR) Could you also help update changelog-3.2 and https://github.com/etcd-io/etcd/blob/master/Documentation/upgrades/upgrade_3_3.md#upgrade-checklists (specify which 3.2 patch version has the fix). |
CHANGELOG: update 3.2 changelog and 3.3 upgrade document for #11691
fix issue: #11689