Difference between revisions of "Puppet/bp-cinder-volume-multi-backend"
< Puppet
(init) |
m (Mgagne moved page Puppet-openstack/bp-cinder-volume-multi-backend to Puppet/bp-cinder-volume-multi-backend) |
||
| (10 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | + | ==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=== | ||
| + | currently you can | ||
| + | |||
| + | 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=== | ||
| + | |||
| + | class { 'cinder::volume': } | ||
| + | |||
| + | cinder::backend::rbd {'images': | ||
| + | rbd_user => 'images', | ||
| + | rbd_pool => 'images', | ||
| + | } | ||
| + | |||
| + | cinder::backend::iscsi {'local-lvm': | ||
| + | iscsi_ip_address => '10.0.0.2', | ||
| + | } | ||
| + | |||
| + | cinder::volume_type {'standard': | ||
| + | backends => ['images', 'local-lvm'] | ||
| + | |||
| + | ===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 volume_type [http://www.sebastien-han.fr/blog/2013/04/25/ceph-and-cinder-multi-backend/ example] | ||
| + | # if types are default, must allow for a default type (so scheduler can consider multiple seperate providers equally) | ||
| + | |||
| + | ==Components== | ||
| + | |||
| + | ===backends=== | ||
| + | ===volume_types=== | ||
Latest revision as of 21:17, 2 April 2015
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
currently you can
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
class { 'cinder::volume': }
cinder::backend::rbd {'images':
rbd_user => 'images',
rbd_pool => 'images',
}
cinder::backend::iscsi {'local-lvm':
iscsi_ip_address => '10.0.0.2',
}
cinder::volume_type {'standard':
backends => ['images', 'local-lvm']
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 volume_type example
- if types are default, must allow for a default type (so scheduler can consider multiple seperate providers equally)