Open Stack

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

Absolutely +1 on converging on a single implementation. That was
our intent on the ceilometer side from the get-go, to promote a
single implementation to oslo that both projects could share.

This turned out not to be possible in the short term when the
non-consistent aspect of the Ironic implementation was discovered
by Nejc, with the juno-3 deadline looming. However for kilo, we
would definitely be interested in leveraging a best-of-breed
implementation from oslo.

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

Fair enough, I was just allowing for the possibility that avoidance
of needless re-mapping hasn't as high a priority on the ironic side
as it was for ceilometer.

Cheers,
Eoghan