wrong compute hash ring position of fnv1a_ch

[toopa2002]

I found some wrong compute hash ring position when using fnv1a_ch hash algorithm compare to Carbon-c-relay.

• Graphite-Web setting

  
  CARBONLINK_HASHING_TYPE = 'fnv1a_ch'
  CARBONLINK_HOSTS = ["127.0.0.1:7002:a", "127.0.0.1:7112:b", "127.0.0.1:7212:c", "127.0.0.1:7312:d", "127.0.0.1:7412:e", "127.0.0.1:7512:f", "127.0.0.1:7612:g", "127.0.0.1:7712:h"]

* Carbon-C-Relay setting

cluster local fnv1a_ch 127.0.0.1:2013=a 127.0.0.1:2113=b 127.0.0.1:2213=c 127.0.0.1:2313=d 127.0.0.1:2413=e 127.0.0.1:2513=f 127.0.0.1:2613=g 127.0.0.1:2713=h ;

Some of invalid compute:
* replication_key='41-e'
* carbon-c-relay position=1526
* graphite-web position=121242316

key='41-e' big_hash = ('%X' % int(fnv32a(str(key)))).lower() big_hash '73a02cc' big_hash[:4]
'73a0' big_hash[4:] '2cc'

It need to prepend "0" to "bigh_hash" to make to computation correct.

>>> big_hash = ('%08X' % int(fnv32a(str(key)))).lower()
>>> big_hash[:4]
'073a'
>>> big_hash[4:]
'02cc
```'

[deniszh]

Right, thanks for reporting this. I supposed to be python 2.6 compatible when backporting it to 0.9.x but missed obvious fact that 'X' has no leading zeros (master using format({:x}) which has it). Fixed in PR #1761

[toopa2002]

It is very fast fix. I'm going to create a pull request, but you are faster. Thank you.

[deniszh]

You're welcome! and thanks for the fix too