[openstack-dev] [Ironic] (Non-)consistency of the Ironic hash ring implementation

Nejc Saje nsaje at redhat.com
Thu Sep 4 07:53:04 UTC 2014



On 09/04/2014 01:37 AM, Robert Collins wrote:
> On 4 September 2014 00:13, Eoghan Glynn <eglynn at 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 :)
>
> -Rob
>
>




More information about the OpenStack-dev mailing list