df647d0ccd
We've built our multibackend support by abusing oslo.messaging's Target.server and appending '@backend-name' prefix to the hostname. This made implementation easier, as we're simply treating multibackends as totally separated services. While this worked in RabbitMQ, zmq is communicating explicitly using hostnames, so appending anything to hostname in Target.server breaks communication. This commit modifies the messaging layer of cinder-volume to use Target.topic to distinguish backends. This is done by: * Making cinder-volume listen on new RPC server, with Target.server set to raw hostname, and topic is set to 'cinder-volume.host@backend'. 'cinder-volume' prefix is added to keep compatibility with Newton's services (we're relying on how RabbitMQ transport is implemented in oslo.messaging). * Note that old RPC server listening on 'cinder-volume' topic is left there, as we need it to recieve fanout messages from scheduler. * When sending a message to cinder-volume, we're sending it using Target.topic to route it to correct host and backend. For backward compatibility it's controlled by conditional based on RPC version pin. Closes-Bug: 1630975 Related-Bug: 1440631 Implements: cinder-zeromq-support Change-Id: I22efbeb97e11838139e2b33226d1c10094d27c1d
Team and repository tags
CINDER
You have come across a storage service for an open cloud computing service. It has identified itself as Cinder. It was abstracted from the Nova project.
- Wiki: http://wiki.openstack.org/Cinder
- Developer docs: http://docs.openstack.org/developer/cinder
Getting Started
If you'd like to run from the master branch, you can clone the git repo:
For developer information please see HACKING.rst
You can raise bugs here http://bugs.launchpad.net/cinder
Python client
https://git.openstack.org/cgit/openstack/python-cinderclient