receive: Include current config hash in forward requests #3138
Conversation
pkg/receive/handler.go
Outdated
| // The replica value in the header is one-indexed, thus we need >. | ||
| if rep > h.options.ReplicationFactor { | ||
| return errBadReplica | ||
| } | ||
|
|
||
| if h.hashring.ConfigHash() != config { | ||
| return errHashringConfigMismatch |
There was a problem hiding this comment.
I'm actually not certain anymore whether erroring is really the right thing to do. We should always favor availability over consistency I think so we should rather accept the write but log or record in a metric that this has happened.
There was a problem hiding this comment.
👍 Alright. Make sense. It'd simplify things. I'm gonna add a metric and log this event.
There was a problem hiding this comment.
If we won't fail until we run mutlple multi-tsdb's per hashring configuration (as it suggested in #3141), the config hash is only going to be informative not actionable.
kakkoyun
force-pushed
the
hashring_hash
branch
from
3aa1cfa
to
c603aad
Compare
kakkoyun
force-pushed
the
hashring_hash
branch
2 times, most recently
from
ceff9cd
to
ad1fb2c
Compare
kakkoyun
changed the title
Signed-off-by: Kemal Akkoyun <[email protected]>
Signed-off-by: Kemal Akkoyun <[email protected]>
Signed-off-by: Kemal Akkoyun <[email protected]>
Signed-off-by: Kemal Akkoyun <[email protected]>
kakkoyun
force-pushed
the
hashring_hash
branch
from
8aa3585
to
c7d849f
Compare
|
@brancz Do you see any value to merge this? Or should I just close this one? |
|
I think since we're splitting the architecture for the receive component, we can close this. Wdyt? |
|
@brancz Sounds good to me 👍 |
Signed-off-by: Kemal Akkoyun [email protected]
Changes
Verification
make test-local