-
Notifications
You must be signed in to change notification settings - Fork 4.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
Avoid raft change when no config is provided on persistNewRootAndConfig #12298
Conversation
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.
Thank you for the PR! I think you are correct, we can avoid this unnecessary raft apply, nice find!
This comparison is already pretty challenging to read. I think we'd benefit from extracting this to a function. That allows us to break up the logic a little bit like this:
(writing this quickly, so the naming and logic may not be right)
func shouldPersistRootAndConfig(root *structs.CARoot, prevConfig, nextConfig *structs.CAConfiguration) bool {
if root != nil {
return true
}
if nextConfig == nil {
return false
}
return nextConfig.Provider != prevConfig.Provider || !reflect.DeepEqual(nextConfig.Config, prevConfig.Config)
}
It would also be great to have a test case that shows this change fixes the problem. I guess that updating the config in the primary in such a way that changes the CARoot
struct, but does not create a new root cert would accomplish that. This #11811 (comment) mentions one case I noticed where this can happen.
cca9bfa
to
f447167
Compare
Hi @dnephin I made the suggested changes and added a test case for this. I also added a chagelog file. |
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.
Thanks for adding the test! Sorry it has taken me a few weeks to respond.
This is looking great. I think the test case is close, but doesn't quite exercise the behaviour we want yet. I left a few suggestions for how to remove some things we no longer need, and to better test the behaviour that was changed.
if newConfig == nil { | ||
return false | ||
} |
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 calling this out for anyone else reviewing or reading over this PR.
This condition is the new one that fixes the problem. Previously we were checking if config != nil
to prevent reading a field from a nil. Here we instead say that if the config is nil then we know there is nothing to update, otherwise use the existing logic to see if the config has changed.
- This avoids a change to the raft store when no roots or config are provided to persistNewRootAndConfig
b8db8b9
to
f429c1a
Compare
Hi @dnephin I pushed a new commit with the suggested changes. I hope I have understood everything correctly. |
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.
Nice! This is exactly what I was thinking. I think with these two small changes this should be ready to merge. I'll commit these suggestions and see if CI is happy.
Also change the path used for the secondary so that both primary and secondary do not overwrite each other.
f7032aa
to
161206e
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.
Looks like CI is happy with those changes. Thanks for making this improvement!
🍒 If backport labels were added before merging, cherry-picking will start automatically. To retroactively trigger a backport after merging, add backport labels and re-run https://circleci.com/gh/hashicorp/consul/601036. |
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
hashicorp#12298 introduced an improvement to prevent raft commit for no-op operations, but while moving conditions into a function, author inversed the logic while keep same boolean operations. As a consequence, this prevents one to update provider config of a secondary CA. Correct code was suggested in a review comment anyway, so apply it: hashicorp#12298 (review)
I saw in the consul logs that every 10 minutes:
I checked that actually no change was made to the roots or configuration so I started to look at the code and I think I found the problem.
persistNewRootAndConfig is called throught the replication process with nil config and roots when no change needs to be performed.
With this PR, a change to the raft store is avoided when no roots or config are provided to persistNewRootAndConfig