Jump to: navigation, search

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

(→‎Use a single cinder-volume backend)
 
(5 intermediate revisions by one other user not shown)
Line 1: Line 1:
 
==Overview==
 
==Overview==
  
−
We should be able to support [https://wiki.openstack.org/wiki/Cinder-multi-backend Cinder-multi-backend]
+
We should be able to support [[Cinder-multi-backend]]
  
 
This moving this way would allow us to support multiple concurent backends.
 
This moving this way would allow us to support multiple concurent backends.
Line 17: Line 17:
  
 
===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===
−
...
+
 
 +
  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 ===
 
===Use three or more cinder-volume backends and assign them two to one type and the other to another ===
Line 26: Line 39:
 
# must configure as many supported backends as possible
 
# must configure as many supported backends as possible
 
# must be comptible with only defining one single backend
 
# must be comptible with only defining one single backend
−
# must configure cinder type [http://www.sebastien-han.fr/blog/2013/04/25/ceph-and-cinder-multi-backend/ example]
+
# 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)
 
# if types are default, must allow for a default type (so scheduler can consider multiple seperate providers equally)
  
Line 32: Line 45:
  
 
===backends===
 
===backends===
−
===storage_types===
+
===volume_types===

Latest revision as of 21:17, 2 April 2015

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

  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

Retrieved from "https://wiki.openstack.org/w/index.php?title=Puppet/bp-cinder-volume-multi-backend&oldid=76794"