if commit "MEDIUM: lb-chash: Deterministic node hashes based on server address"
introduces breaking change .... and nobody complained ... likely customers
are tolerant to such commit (as well as reverting)
вс, 7 сент. 2025 г. в 10:42, Willy Tarreau <w...@1wt.eu>:
> Hi Alex,
>
> On Sun, Sep 07, 2025 at 10:32:52AM +0200, Aleksandar Lazic wrote:
> > Hi Willy.
> >
> > On 2025-09-05 (Fr.) 16:47, Willy Tarreau wrote:
> > > Hi all,
> > >
> > > I've got a report of consistent hash delivering different hashes since
> 3.0 with
> > > commit faa8c3e02 ("MEDIUM: lb-chash: Deterministic node hashes based
> on server
> > > address").
> > >
> > > The cause is a mistake in the ID-based key calculation (the hash is
> applied
> > > twice and the ID range scaling was dropped). The fix is trivial:
> > >
> > > --- a/src/lb_chash.c
> > > +++ b/src/lb_chash.c
> > > @@ -123,7 +123,7 @@ static inline u32
> chash_compute_server_key(struct server *s)
> > > case SRV_HASH_KEY_ID:
> > > default:
> > > - key = full_hash(s->puid);
> > > + key = s->puid * SRV_EWGHT_RANGE;
> > > break;
> > > }
> >
> > For which directive/config can I grep to verify if the consistent hash
> is in use?
>
> Good point, I forgot the most important: you're affected if you're in 3.0+
> with "hash-type consistent" and no "hash-key" (or "hash-key id") setting in
> the same backend which delivers traffic to cache nodes. And if you have
> them
> but upgraded from 2.9 or older without noticing, it means that your load
> doesn't have an impact on the caches.
>
> Thanks,
> Willy
>
>
>
