Assumptions

that there can be > 1 of the same backend, so there _has_ to be a mapping in the config between the names of a backend (Backend1, backend2) and its configuration settings.

Ways to achieve

1) Like nova-api, spawn off multiple cinder-volume children, each consisting of its own "backend". See https://gist.github.com/4588322
2) A single cinder-volume, with a special manager impl, for multiple backends, where each method has the backend defined in it. See https://gist.github.com/4588988
3) DONT DO IT... As in, create multiple cinders with their own config/stack/port and let your scheduler decide which one to talk to

you dont modify the managers. Its just that > 1 is spawned and represented by a independent process.
Its easy to specify a differing Q name based on the name of the backend (backend1, backend2....etc)

There must be a way to "pass down" the fact that each child is a spawned instance of a particular backend. Lets call it backend1. This would have to be propagated thru the service code ( server = service.Service.create.....) in the binscript. the nova-api code _does_ do that, but its because the paste configs all work off the name of the app. So single app or multi app binscripts dont change that behavior.
The impls would need some notion of knowing if they are multi backend, then use a different config value, because of assumption 1. - Not sure how this would pan out...
There would need to be some Q fun in the scheduler since they go to different Qs based on the backend name. Just a different routing key i assume...

Same Q, Same process, and the notion of the manager/impl/messageQ dont have to change in service.py

Every message sent down would have to have a new parameter added to it, backend=BLAH, where BLAH is the name of the backend.
A new multi manager would need to be created with every method being _exactly_ the same as the regular manager, but just having an extra param like the messages sent down.
The impls would need some notion of knowing if they are multi backend, then use a different config value, because of assumption 1. - This would be easier if the MultiManager was init'ing the children since we can put the params in the impls init methods.

Very little to do. Make sure there is no Q collision if > 1 cinder stack is started on same node

The entire cinder stack for X backends will live on your nodes. if u have 10 backends thats 10*3 (api/scheduler/volume) for each