Difference between revisions of "Puppet/bp-cinder-volume-multi-backend"
< Puppet
(→Use a single cinder-volume backend) |
|||
Line 8: | Line 8: | ||
===Use a single cinder-volume backend=== | ===Use a single cinder-volume backend=== | ||
− | ... | + | |
+ | class { 'cinder::volume': } | ||
+ | |||
+ | class { 'cinder::volume::iscsi': | ||
+ | iscsi_ip_address => '10.0.0.2', | ||
+ | } | ||
===Use two or more cinder-volume backends and assign them to different types=== | ===Use two or more cinder-volume backends and assign them to different types=== |
Revision as of 23:17, 22 October 2013
Contents
Overview
We should be able to support Cinder-multi-backend
This moving this way would allow us to support multiple concurent backends.
user story
Use a single cinder-volume backend
class { 'cinder::volume': } class { 'cinder::volume::iscsi': iscsi_ip_address => '10.0.0.2', }
Use two or more cinder-volume backends and assign them to different types
...
Use three or more cinder-volume backends and assign them two to one type and the other to another
...
Requirements
- must configure as many supported backends as possible
- must be comptible with only defining one single backend
- must configure cinder type example
- if types are default, must allow for a default type (so scheduler can consider multiple seperate providers equally)