cinder manage command it’s only for independent rbd volumes. However, manage an already-managed volumes is allow by the api and there’re not exception raised.
When you try to manage an already-managed volume, you received an unhandled error: ‘UnboundLocalError: local variable ‘rbd_image’ referenced before assignment’
How to reproduce:
1)Create a volume:
‘cinder create 1 –name vol1’
2) try to manage the volume (you can check the host with ‘cinder show <vol1’s ID>’):
cinder manage <vol1’s host> <vol1’s ID>
3) On the c-vol you can appreciate the unhandled error.
When this happens the RBD driver should handle the error.
The RBD driver should catch the exception and show a custom message notifying the user.
So, trying to handle the problem inside the rbd driver.
Continue reading “Working in my first RBD bug”
./stack (you may have a cluster issue):
(1) You need to check out your ceph configuration and see if everything is ok.
~/devstack$sudo ceph -s
To check the size of your cluster:
Continue reading “Let’s play with Cinder and RBD (part 1)”
Since 3 weeks, I’m working on Cinder RBD (Ceph) to manage and unmanage snapshot.
I can’t start writing about my project without giving to this blog some previous data about Block Storage, RADOS, RBD, and Ceph (which is my best friend now)..
As I wrote before, Cinder is a Block Storage service for OpenStack, but what does this mean?
The Block Storage service provides persistent block storage resources that Compute instances can consume. In addition, you can write images to a Block Storage device for Compute to use as a bootable persistent instance. It service does not provide a shared storage solution like NFS. With the Block Storage service, you can attach a device to only one instance.
Cinder’s designed to present storage resources to end users that can be consumed by the OpenStack Compute Project (Nova). This is done through the use of either a reference implementation (LVM) or plugin drivers for other storage.
Cinder 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.
Basic resources offered by the Block Storage service
- Volumes : allocated block storage resources that can be attached to instances as secondary storage or they can be used as the root store to boot instances. Volumes are persistent R/W block storage devices most commonly attached to the compute node through iSCSI.
- Snapshots : a read-only point in time copy of a volume. The snapshot can be created from a volume that is currently in use or in an available state. The snapshot can then be used to create a new volume through create from snapshot.
- Backups : an archived copy of a volume.
So, Cinder provides:
- cinder-api : a WSGI app that authenticates and routes requests throughout the Block Storage service.
- cinder-scheduler : schedules and routes requests to the appropriate volume service.
- cinder-volume : manages Block Storage devices, specifically the back-end devices themselves.
- cinder-backup : provides a means to back up a Block Storage volume to OpenStack Object Storage (swift).
*If you want to read more please check out the official OpenStack documentation.