Difference between revisions of "Cinder"
(Add details around the required volume stats)
(→Minimum Driver Features)
|Line 48:||Line 48:|
'''NOTE:''' If the driver in unable to provide a value for free_capacity_gb or total_capacity_gb, keywords can be provided instead. Please use 'unknown' if the array cannot report the value or 'infinite' if the array has no upper limit.
'''NOTE:''' If the driver in unable to provide a value for free_capacity_gb or total_capacity_gb, keywords can be provided instead.
Please use 'unknown' if the array cannot report the value or 'infinite' if the array has no upper limit.
Revision as of 23:56, 16 February 2013
OpenStack Block Storage ("Cinder")
- Python Cinder client
- Block Storage API documentation
What is Cinder ?
The goal of the Cinder project is to separate the existing nova-volume block service into its own project.
- 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
Initial list of topics to discuss at the Havana summit:
- Reporting specific errors to the client, for example: https://bugs.launchpad.net/cinder/+bug/1116077
- Driver class hierarchy: https://blueprints.launchpad.net/cinder/+spec/reorganize-connection-specific-cinder-driver-code
Minimum Driver Features
A Cinder driver must implement the following features in order to be accepted by the Cinder team for a given milestone release.
- Volume Create/Delete
- Volume Attach/Detach
- Snapshot Create/Delete
- Create Volume from Snapshot
- Get Volume Stats
The current list of volume stats that should be populated by the driver include:
NOTE: If the driver in unable to provide a value for free_capacity_gb or total_capacity_gb, keywords can be provided instead. Please use 'unknown' if the array cannot report the value or 'infinite' if the array has no upper limit.
- Above Release features plus
- Copy Image to Volume
- Copy Volume to Image
- Clone Volume
It is strongly encouraged that you implement all the features for a given release if possible. However, the Cinder team understands that the turnaround time might be too tight for some, due to corporate legal approval, new features landing at the very end of a sprint, etc… Each major release the list will be updated to include additions that will be required to be supported.
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)http://wiki.openstack.org/CinderMeetings
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 and nova-volumes 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.