Jump to: navigation, search

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

m
 
(8 intermediate revisions by one other user not shown)
Line 1: Line 1:
=Blueprint for cinder-volume to support multiple concurent storage drivers=
+
==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 page has been created to start tracking discussion on direction prior to implmentation.
+
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

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