-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Receive: Allow setting hashing algorithm per tenant in hashrings config #5653
Conversation
@fpetkovski could you pls review if this is what you mean in the issue? |
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, this looks good to me 👍
case AlgorithmKetama: | ||
return newKetamaHashring(endpoints, SectionsPerNode, replicationFactor) | ||
default: | ||
return simpleHashring(endpoints) |
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.
If an invalid algorithm is specified, do we just fallback to the hashmod algorithm?
I feel a better way is to either:
- Return non-exist error and let users know this is wrong.
- Fall back to the default one. But have a log to tell that the specified algorithm is wrong.
Those 2 options are better than ignoring the error.
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.
@yeya24 I think Option 1 is better. Thought of that myself. But that would change the logic of the current newMultiHashring() a little bit. Would that cause a backward compatibility problem?
I see that we have an errors package at https://github.com/thanos-io/thanos/tree/main/pkg/errors but that doesn't seem to be used much? If we go with option 1, should I use that one or the github.com/pkg/errors
one?
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.
What would be the behavior though? Right now we do not return error as hashring creation (so to speak) "cannot" fail. Should we return error and ignore a hashring with invalid algorithm? Or how would we like to handle this?
This is why option 2 looked better, since we can just warn and fall back.
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.
When I look at this issue now, I feel either way is okay to me.
If we go with option 1, even if it is wrong, it is just one-off. If we go with option 2, it is also fine to me as this is better than current behavior.
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.
Would be good to address @yeya24's comment, otherwise looks good!
CHANGELOG.md
Outdated
@@ -15,6 +15,7 @@ We use *breaking :warning:* to mark changes that are not backward compatible (re | |||
- [#5655](https://github.com/thanos-io/thanos/pull/5655) Receive: Fix recreating already pruned tenants. | |||
|
|||
### Added | |||
- [#5653](https://github.com/thanos-io/thanos/pull/5653) Receive: Allow setting hashing algorithm per tenant in hashrings config |
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.
Nit: Can we specify that the hashring config from file has precedence over the flag?
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.
Yeah I'm thinking we can have a log telling where we take the algorithm from.
Also, we need to edit the receive.md
doc and the description of receive.hashrings-algorithm
flag (anything else?)
Where can I edit the description of the receive.hashrings-algorithm
flag?
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.
In here: https://github.com/thanos-io/thanos/blob/main/cmd/thanos/receive.go#L820, I believe the .md
is automatically generated based on this description
Just thought of this case, currently if users specify the algorithm as thanos/pkg/receive/hashring.go Lines 26 to 27 in fb11fc7
|
Preferably we should convert the string to lowercase (if this is not already done by the library we use for flags?) and accept it, more user friendly. |
I am not sure I like where this rabbit hole is taking us :) What about adding validation here so that we can take the guesswork out: https://github.com/thanos-io/thanos/blob/main/pkg/receive/hashring.go#L289? That should resolve @yeya24's comment if I'm not mistaken. |
I made all the required changes. There're still some failed checks because I'm having a problem with |
pkg/receive/hashring.go
Outdated
@@ -296,6 +292,21 @@ func HashringFromConfig(algorithm HashringAlgorithm, replicationFactor uint64, c | |||
if len(config) == 0 { | |||
return nil, errors.Wrapf(err, "failed to load configuration") | |||
} | |||
|
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.
gofmt: File is not gofmt
-ed with -s
ℹ️ Learn about @sonatype-lift commands
You can reply with the following commands. For example, reply with @sonatype-lift ignoreall to leave out all findings.
Command | Usage |
---|---|
@sonatype-lift ignore |
Leave out the above finding from this PR |
@sonatype-lift ignoreall |
Leave out all the existing findings from this PR |
@sonatype-lift exclude <file|issue|path|tool> |
Exclude specified file|issue|path|tool from Lift findings by updating your config.toml file |
Note: When talking to LiftBot, you need to refresh the page to see its response.
Click here to add LiftBot to another repo.
Was this a good recommendation?
[ 🙁 Not relevant ] - [ 😕 Won't fix ] - [ 😑 Not critical, will fix ] - [ 🙂 Critical, will fix ] - [ 😊 Critical, fixing now ]
pkg/receive/hashring.go
Outdated
@@ -296,6 +292,21 @@ func HashringFromConfig(algorithm HashringAlgorithm, replicationFactor uint64, c | |||
if len(config) == 0 { | |||
return nil, errors.Wrapf(err, "failed to load configuration") | |||
} | |||
|
|||
if (algorithm != "hashmod") && (algorithm != "ketama") { | |||
log.Println("The specified algorithm is incorrect. Fall back to hashmod algorithm") |
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.
Can we log more information about the hashring to help debugging & problem solving? For example, the hashring name and tenants could be useful.
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.
Sure!
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 your contribution, @haanhvu 🙇
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.
@douglascamata Do you think log.Println
is good enough for all cases?
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.
Unfortunately, I don't think so, @haanhvu. It's better to use our chosen logging library ("github.com/go-kit/log"
), which might require that you send down the logger as a parameter to this function and then do something like:
# import "github.com/go-kit/log/level"
level.Warning(logger).Log(...)
I think Warning
is the best level as this doesn't stop Receive from starting up.
@haanhvu any updates on this one? |
@matej-g There're some small fixes left to do (mostly the log as @douglascamata suggested). But I need to finish #5777 first before getting back to this. Can't be in two rabbit holes at the same time... |
No worries @haanhvu, I was just sifting through PRs and wanted to know latest status, carry on and thank you 😊 |
@matej-g @douglascamata @yeya24 Hey about the log, I'm not sure where to put it for now. In #5777 we edited and deleted a lot of functions in So I think we can add the log later, after #5777 merged. Is that ok? |
Sounds good to me. Not sure what the maintainers think. |
Signed-off-by: haanhvu <haanh6594@gmail.com>
Signed-off-by: haanhvu <haanh6594@gmail.com>
Signed-off-by: haanhvu <haanh6594@gmail.com>
I made all the required changes. Please help review! |
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.
Neat and clean. LGTM! 🚀
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!
I completely forgot. Do we need to add test? Like a simple test that shows the algorithm in hashring config will overwrite the global algorithm? |
@haanhvu tests are always welcome! :D |
Signed-off-by: haanhvu haanh6594@gmail.com
fixes #5567
Changes
Receive: Allow setting hashing algorithm per tenant in hashrings config
Verification