How To Contribute a driver to Cinder
Before you write any code
- The most important place to start is the How To Contribute Page:
- Hopefully you already familiarized yourself with the Cinder wiki page
Cinder offers a reference implementation that should be used as a model. The reference implementation driver file is cinder/volume/drivers/lvm.py, not to be mistaken for cinder/volume/driver.py which is the base class that all of the drivers inherit from. You must implement all of the methods that exist as core features (check out the driver compat matrix from the cinder wiki).
Note that there are a lot of options that show up there regarding iSCSI targets etc, but this gives you an idea of the expectations in terms of features that are implemented and some of the behaviors. I strongly recommend loading up devstack (you're going to need it to test your driver anyway) and play around with the default LVM. It's really important that you get a feel for how Ciinder works and interacts with the other OpenStack projects before you get too far along.
We have a development channel on freenode: #openstack-cinder There are developers here round the clock, it's a great resource for you get started. Log in, ask questions, don't stare at code in isolation for a week... if you're stuck on something just ask. There' also no need to start off with "Can I ask a question"... you likely won't get a response. Just type in your question, that way anybody monitoring the channel that might know the answer can step in and answer.
Before You Submit Code
There's a number of things that you should get from the "how to contribute guide" but to reiterate as they're often missed:
- You need to submit a detailed blueprint in Launchpad introducing your driver and submitting it for approval
- Have a general idea of how Cinder works, what it's used for, why the other projects in OpenStack may or may not use it
- Fully understand the difference between ephemeral storage on the Nova side versus the persistent storage offered by Cinder
Oh, and don't forget
Unit tests for new code are required. We're in the process of converting everything to use mock (rather than mox) for our unit tests. Be sure when writing unit tests and setting up fakes to use mock, examples of it's usage can be found in the existing tests like cinder/tests/test_volume.py.
There's an expectation that unit tests leave the system as they found it. That means using things like the tempfile module if you have to write out some persistent data somewhere for your test.
There's an expectation that any backend device and every driver that is submitted can successfully run and pass the existing OpenStack Tempest tests. Every commit in OpenStack goes through an automated gate test, all we ask here is that since we won't have your backend device that you run this yourself an make sure you've covered all of the required features and that everything works as expected. We have a script to help you with that in the devstack tree: https://github.com/openstack-dev/devstack/tree/master/driver_certs. This is relatively new and needs some more flushing out as well as some documentation, but it's a start and it should progress and grow as time goes by.