> >> > 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev