Jump to: navigation, search

Cinder/MultiVolumeBackend

< Cinder
Revision as of 22:59, 8 August 2012 by Rnirmal (talk)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Summary

Allow managing multi volume backends from a single volume manager. Right now there's a 1-1 mapping of manager-driver. This blueprint aims to provide suport for 1-n manager-drivers, where by certain volume drivers that really don't depend on local host storage can take advantage of this to manager multi backends without having to run multi volume managers.

The thought is to use the existing configuration sections to distinguish the various drivers to load for a single volume manager.

Release Note

  1. Run one or more drivers with a single volume manager.
  2. Adds support for volume backends within the volumes table to distinguish which driver to choose for a certain volume.

Rationale

Currently there's no way to manage multi backends, it's 1-1. This provides more flexibility for an operator manager several backends, where they could just run 2 or 3 volume managers for load balancing instead of having to run multi instances of volume managers for each of the backends plus if they need to load balance it.

User stories

No user facing impact.

Design

Provide a way in the configuration to support multiple sections per volume driver configuration.

Implementation

Some code changes and database changes too.

Code Changes

Mostly update the volume manager to support multi drivers and update the drivers to load configuration on startup rather than loading then when they need it.

Migration

Additions:

  1. volume_backends
    1. created_at - datetime
    2. updated_at - datetime
    3. deleted_at - datetime
    4. deleted - tinyint(1)
    5. id - int(11)
    6. name - varchar(255)
    7. description - varchar(255)

Modifications:

  1. volumes
    1. backend_id - int(11) Foreign key to volume_backends.id

Test/Demo Plan

TBD