Hash ring implementation is not consistent

[Nejc Saje]

As brought up on the ML (http://lists.openstack.org/pipermail/openstack-dev/2014-September/044566.html), the hash ring implementation in Ironic is not consistent, since when adding a conductor, instead of 1/#conductors of hosts getting remapped, an unbound amount of them will get remapped at the moment..

[Eoghan Glynn (eglynn)]

Can someone on ironic-drivers do an Importance and Milestone assignment for this bug?

(That would be useful from the PoV of planning a best-of-breed hash ring implementation to use for both ceilometer and ironic)

Thanks!
Eoghan

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/118932
Committed: https://git.openstack.org/cgit/openstack/ironic/commit/?id=b272e61218a93fa3054a4fbc6bf3c667c93e9d11
Submitter: Jenkins
Branch: master

commit b272e61218a93fa3054a4fbc6bf3c667c93e9d11
Author: Robert Collins <email address hidden>
Date: Thu Sep 4 00:47:13 2014 +0000

    Make hash ring mapping be more consistent

    Nejc Saje reported on the openstack-dev list that our hash ring was not
    stable as hosts were added or removed. This is a significant issue since
    the hash ring is meant to minimize the impact of adding or removing
    conductors to only approximately the change in capacity.

    IMPORTANT: When this patch is added to a running Ironic environment it
    will cause ring calculations to change. This will cause most existing
    node -> conductor mappings to be invalid, which will cause existing
    deployed nodes to be unable to reboot (if using a netbooting driver like
    pxe_ipmi). The cluster will self-correct over time as the periodic task
    _sync_hash_ring() rebuilds PXE environments.

    NOTE: The meaning of the hash_partition_exponent configuration setting
    had to be changed - if we define the total number of partitions of the
    ring via it then adding a host simultaneously removes some partitions of
    each existing host as well as adding new partitions from the new host -
    this results in more perturbation. Instead we use it to define the
    number of partitions per host. Existing deployments will continue to
    work, but may be able to reduce some CPU overhead by shrinking their
    setting.

    Change-Id: Iad3c9f6b460e9162ca91d5719e42f7950f2f18df
    Closes-Bug: #1365334
    DocImpact: See above.
    UpgradeImpact: See above.