Map instances to conductors using a consistent hashing algoritm

Registered by aeva black on 2013-11-21

In the many discussions we've been having about how to run >1 ir-cond instance, some points have consistently been raised:
- we may need to route RPC messages to what ever conductor(s) is/are providing the TFTP environment for a given node
- we will need to inform Neutron of an instance:conductor mapping, so that it can appropriately forward DHCP BOOT requests (this depends on a separate BP to incorporate support for Neutron)
- we will need to update that mapping in Neutron when the mapped conductor becomes unavailable (this depends on "take over node" functionality in the conductor, which will be done separately as well)

One solution to this would be to implement a static scheduling service within Ironic, whose job is to manage the placement of instances. We have opted for a distributed architecture, and thus far avoided any static mappings.

A better option -- what this blueprint is proposing -- is to use a consistent hashing algorithm to associate instances to conductors. The number of buckets and number of replicas should be config options. Since Ironic already maintains a database table of conductor services, what drivers each conductor supports, and a heartbeat, this table can be used as a shared source-of-truth for the list of active/inactive conductors.

The details of this are being hashed out in this etherpad:

https://etherpad.openstack.org/p/IronicConsistentHashingForInstances

Blueprint information

Status:
Complete
Approver:
aeva black
Priority:
High
Drafter:
aeva black
Direction:
Approved
Assignee:
aeva black
Definition:
Approved
Series goal:
Accepted for icehouse
Implementation:
Implemented
Milestone target:
milestone icon 2014.1
Started by
aeva black
Completed by
aeva black

Related branches

Sprints

Whiteboard

Gerrit topic: https://review.openstack.org/#q,topic:bp/instance-mapping-by-consistent-hash,n,z

Addressed by: https://review.openstack.org/58607
    Implement consistent hashing common methods

Addressed by: https://review.openstack.org/58895
    WIP - implement conductor rebalance method

Gerrit topic: https://review.openstack.org/#q,topic:hash-ring,n,z

Addressed by: https://review.openstack.org/58894
    Add prepare, cleanup, takeover methods to deploy

Addressed by: https://review.openstack.org/59794
    Add config option for # of conductor replicas

Addressed by: https://review.openstack.org/59795
    Improve method to get list of active conductors

Gerrit topic: https://review.openstack.org/#q,topic:drivers-list-hosts,n,z

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.