Open Stack

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),

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

-Rob


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud