- 1 OpenStack Block Storage ("Cinder")
- 1.1 Related projects
- 1.2 What is Cinder ?
- 1.3 Reasoning:
- 1.4 Documents:
- 1.5 Minimum Driver Features
- 1.6 Keeping informed and providing CONSTRUCTIVE INPUT
- 1.7 Concerns from the community:
- 1.8 Cinder Core Drivers
- 1.9 Notes About Submitting Patches
- 1.10 Cinder Plugins
OpenStack Block Storage ("Cinder")
|[Cinder on launchpad (including bug tracker and blueprints)]|
|[OpenStack Block Storage Service Administration Guide]|
- Python Cinder client
- Block Storage API documentation
What is Cinder ?
Cinder provides an infrastructure for managing volumes in OpenStack. It was originally a Nova component called nova-volume, but has become an independent project since the Folsom release.
- Nova is currently a very large project; managing all of the dependencies in linkages of services within Nova can make the ability to advance new features and functionality very difficult.
- As a result of the many components and dependencies in Nova, it's difficult for anybody to really have a complete view of Nova and to be a true expert. This makes the job of core team member on Nova very difficult, and inhibits good thorough reviews of bug and blueprint submissions.
- Block storage is a critical component of OpenStack, as such it warrants focused and dedicated attention.
- Having Block Storage as a dedicated core project in OpenStack enables the ability to greatly improve functionality and reliability of the block storage component of OpenStack
- Cinder deep dive (updated for Grizzly): File:Cinder-grizzly-deep-dive-pub.pdf
Minimum Driver Features
See driver dev docs
Keeping consistant with multi backend
In order to maintain consistency with multi backend, do not directly use FLAGS.my_flag, instead use the self.configuration that is provided to the volume drivers. If this does not exist, look @ lvm.py and add it to your driver. using FLAGS.my_flag instead of self.configuration.my_flag will cause multi backend to not work properly. Multi backend relies on the configurations to be within a specific config group in the config file, and the self.configuration abstracts that away from the drivers.
Keeping informed and providing CONSTRUCTIVE INPUT
The Cinder team currently meets on a weekly basis in #openstack-meeting at 16:00 UTC on Wednesdays. I try to keep the meetings wiki agenda page http://wiki.openstack.org/CinderMeetings up to date and follow it. Also keep in mind that anybody is able to add/suggest agenda items via the meeting wiki page.
Of course, there's also IRC... a number of us monitor #openstack-cinder or you can always send a PM to jgriffith (that's me)
Concerns from the community:
Compatibility and Migration:
There has been a significant amount of concern raised regarding "compatibility"; unfortunately this seems to mean different things to different people. For those that haven't looked at the Cinder code or tried a demo in devstack, here are some question/answers:
- Do the same nova client commands I use for volumes today still work the same? YES
- Do the same euca2ools that I use for volumes today still work the same? YES
- Does block storage still work the same as it does today in terms of LVM, iSCSI and the drivers that are curently in place? YES
- Are the associated database tables the same as they are in the current nova volume code? For the most part YES, all volume related tables and columns are migrated, non-volume related tables however are not present
- Does it use the same nova database as we use today? No, it does require a new independent database
- Are you going to implement cinder with complete disregard for my current install and completely change everything out from under me? ABSOLUTELY NOT
- Are you going to test migrating from nova-vol to Cinder? YES
- Are those migration tests going to be done just using fakes/unit tests? NO, we would require running setups, most likely devstack
- Are you planning to provide migration scripts/tools to move from nova to cinder? YES
Additional thoughts to keep in mind:
- The Cinder core team is fortunate enough to have a number of members who currently work for companies that are using OpenStack in production environments. There is a strong representation and the concerns of Providers is in fact a major consideration
- The goal is NOT to throw away nova-volume as it is today, but to separate it, focus on it and improve it.
- Migration is one of the top priorities for introduction of Cinder into Folsom (regardless of whether nova-volume is still in place or not). This is something that is just considered a part of the requirements for the project.
Cinder Core 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
Notes About Submitting Patches
Everyone is welcome to sign the CLA and submit code. Please be sure you familiarize yourself with the "how to contribute guide" (https://wiki.openstack.org/wiki/How_To_Contribute#If_you.27re_a_developer).
Keep in mind, there is a disproportionate number of submitters to reviewers. YOU can help with this!! Anybody is welcome to review patches, jump in, give a review. It's a great way to learn more about the code and to help you make better submissions in the future. It also helps your karma, when you submit a patch if you're an active reviewer core team members are more likely to notice your patch and give it some attention before some others.
How to submit a plugin/driver: https://wiki.openstack.org/wiki/Cinder/how-to-contribute-a-driver
The following plugins (from other sources) are avaialble for this project
- Mellanox Cinder Plugin Mellanox Cinder Plugin