Cinder

Official Title: OpenStack Block Storage Cinder

PTL: Mike Perez <thingee at gmail d0t com>

Mission Statement:

To implement services and libraries to provide on demand, self-service access to Block Storage resources. Provide Software Defined Block Storage via abstraction and automation on top of various traditional backend block storage devices.

[Cinder on launchpad (including bug tracker and blueprints)]

[Source code]

[Developer docs]

Description

Cinder is a Block Storage service for OpenStack. It's designed to allow the use of either a reference implementation (LVM) to present storage resources to end users that can be consumed by the OpenStack Compute Project (Nova). The short description of Cinder is that it virtualizes pools of block storage devices and provides end users with a self service API to request and consume those resources without requiring any knowledge of where their storage is actually deployed or on what type of device.

Project Meetings

See Meetings/Cinder.

Getting in Touch

We use the openstack-dev@lists.openstack.org mailing list for discussions and we all hang out in #openstack-cinder on freenode.

Related projects

• Python Cinder client

Core Volume Drivers

For a list of the core drivers in each OpenStack release and the volume operations they support, see https://wiki.openstack.org/wiki/CinderSupportMatrix

Cinder Plugins

How to submit a plugin/driver: https://wiki.openstack.org/wiki/Cinder/how-to-contribute-a-driver

Cinder Plugin/Driver certification page: https://wiki.openstack.org/wiki/Cinder/certified-drivers

The following plugins (from other sources) are available for this project

• Mellanox Cinder Plugin Mellanox Cinder Plugin

Configuring devstack to use your driver and backend

One of the things you'll be required to do when submitting a new driver is running your backend and driver in a devstack environment and executing the tempest volume tests against it. Currently we provide a driver_cert wrapper (mentioned in the how-to-contribute-a-driver section). One thing that causes some confusion is how do I configure devstack to use my backend device. It used to be that your driver info would have to be added to lib/cinder in devstack to set your options. We then created a cinder/plugin module in devstack. Fortunately though it's MUCH easier than that. For *most* drivers, the only changes that are made consist of cinder.conf file changes. That can easily be accomplished by using devstacks local.conf file (more info here: http://devstack.org/configuration.html). For more complex actions (like the need to install packages etc, the plugin directory in devstack can be used). An example of what this file would look like to add driver FOO is shown below, the default localrc section is included for completeness, but the section of interest is the post-config cinder.conf section:

[[local|localrc]]
_{:# Passwords
ADMIN_PASSWORD=password
MYSQL_PASSWORD=password
RABBIT_PASSWORD=password
SERVICE_PASSWORD=password
SERVICE_TOKEN=password
SCREEN_LOGDIR=/opt/stack/logs
HOST_IP=172.16.140.246
disable_service n-net
enable_service q-svc
enable_service q-agt
enable_service q-dhcp
enable_service q-l3
enable_service q-meta
enable_service neutron}

# These options define expected driver capabilities
TEMPEST_VOLUME_DRIVER=foo
TEMPEST_VOLUME_VENDOR="Foo Inc"
TEMPEST_STORAGE_PROTOCOL=iSCSI

# These options allow you to specify a branch other than "master" be used
CINDER_REPO=https://review.openstack.org/openstack/cinder
CINDER_BRANCH=refs/changes/83/72183/4

# Disable security groups entirely
Q_USE_SECGROUP=False
LIBVIRT_FIREWALL_DRIVER=nova.virt.firewall.NoopFirewallDriver
CINDER_SECURE_DELETE=False

[[post-config|$CINDER_CONF]]
volume_driver = cinder.volume.drivers.foo.FooDriver
foos_var = something
another_foo_var = something-else

Cinder Brick Proposal

https://wiki.openstack.org/wiki/CinderBrick