Difference between revisions of "Puppet/bp-cinder-volume-multi-backend"

Revision as of 23:08, 23 October 2013

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']

alternatly

 #init cinder-volume and config
 class { '::cinder::volume': }
 
 #different backends have different settings so they should be called alone
 cinder::backend::iscsi { 'local-lvm':
   iscsi_ip_address => '10.108.1.1',
   type => 'bronze',
 }
 
 cinder::backend::rbd {'images':
   rbd_user => 'images',
   rbd_pool => 'images',
   type = 'silver',
 }

Use three or more cinder-volume backends and assign them two to one type and the other to another

...

Requirements

1. must configure as many supported backends as possible
2. must be comptible with only defining one single backend
3. must configure cinder volume_type example
4. if types are default, must allow for a default type (so scheduler can consider multiple seperate providers equally)

Components

backends

volume_types