On 09/04/2014 01:37 AM, Robert Collins wrote:
On 4 September 2014 00:13, Eoghan Glynn <egl...@redhat.com> wrote:

On 09/02/2014 11:33 PM, Robert Collins wrote:
The implementation in ceilometer is very different to the Ironic one -
are you saying the test you linked fails with Ironic, or that it fails
with the ceilometer code today?

Disclaimer: in Ironic terms, node = conductor, key = host

The test I linked fails with Ironic hash ring code (specifically the
part that tests consistency). With 1000 keys being mapped to 10 nodes,
when you add a node:
- current ceilometer code remaps around 7% of the keys (< 1/#nodes)
- Ironic code remaps > 90% of the keys

So just to underscore what Nejc is saying here ...

The key point is the proportion of such baremetal-nodes that would
end up being re-assigned when a new conductor is fired up.

That was 100% clear, but thanks for making sure.

The question was getting a proper understanding of why it was
happening in Ironic.

The ceilometer hashring implementation is good, but it uses the same
terms very differently (e.g. replicas for partitions) - I'm adapting
the key fix back into Ironic - I'd like to see us converge on a single
implementation, and making sure the Ironic one is suitable for
ceilometer seems applicable here (since ceilometer seems to need less
from the API),

I used the terms that are used in the original caching use-case, as described in [1] and are used in the pypi lib as well[2]. With the correct approach, there aren't actually any partitions, 'replicas' actually denotes the number of times you hash a node onto the ring. As for nodes&keys, what's your suggestion?

I've opened a bug[3], so you can add a Closes-Bug to your patch.

[1] http://www.martinbroadhurst.com/Consistent-Hash-Ring.html
[2] https://pypi.python.org/pypi/hash_ring
[3] https://bugs.launchpad.net/ironic/+bug/1365334

If reassigning was cheap Ironic wouldn't have bothered having a hash ring :)


OpenStack-dev mailing list

Reply via email to