The document outlines the advancements planned for OpenStack block storage in the Juno release, focusing on user feedback emphasizing the need for improvements in backups, compatibility, and high availability. Key initiatives include enhancing backup capabilities with incremental options, ensuring compatibility across versions, and leveraging existing hardware without vendor lock-in. Additionally, it highlights ongoing efforts in code cleanup, replication setups, and invites community involvement through contributions beyond code.

2. John Griffith: Project Technical lead
IRC: jgriffith
LaunchPad: john-griffith
State of OpenStack Block Storage
A look at what’s planned for Juno (Jun 24, 2014)

3. Theme for Juno:

4. Some of the feedback we’ve received from
“Enterprise” users:
● Continue to improve backups
● Focus on compatibility
● Don’t break upgrades
● Keep giving me something that works
● I need to be able to use my existing gear
● Quality is key
● Need an HA story for the reference driver

5. Improve Backups:
● We currently have a backup to SWIFT (and some others)
● Problem is it’s a full copy of the Volume only
● Difficult to Restore
● More difficult to import (ie DR)
➔Working on adding incrementals for Juno
➔Improving restore including “mange/unmanage”

6. Compatibility:
This means different things to different people
● Compatibility of Cinder versions between upgrades
● Compatibility of features between different backend devices
● MOST importantly, continued compatibility of the reference LVM
driver
➔Goal is for all 3’rd party drivers to implement CI (dsvm-full)
➔Ensures core API functions are tested/supported on all drivers
➔Public visibility of testing and compatibility
➔DONT BREAK THINGS BETWEEN VERSIONS

7. Compatibility Plans for Juno:
● Goal is for all 3’rd party drivers to implement CI (dsvm-full)
● Ensures core API functions are tested/supported on all drivers
● Public visibility of testing and compatibility
● Don’t make it hard for me to upgrade
● DONT BREAK THINGS BETWEEN VERSIONS

8. Something that works:
● See previous slide
● Functions and capabilities should be expected regardless of
backend
● Reference LVM implementation is still the primary focus

9. Using my existing gear:
Common theme seems to be “repurposing gear for OpenStack”
● Vendor participation is good if it’s compatible and it works
● I like having choices
● I like mixing and matching
● I might change my mind in the future
● DONT LOCK ME IN

10. HA for reference implementation:
Multiple paths we hope to work on in Juno
● DRBD based solution
● Volume mirroring across multiple cinder-volume nodes using
software raid

11. What we’re NOT hearing:
● None of the features I want are here
● There are too many options
● I don’t need Block Storage
● You’re missing ‘xyz’

12. Some other things we’re working on:
● Significant code cleanup and fixes in “object sprawl”
● Ability to help admins set up replication
● Concept of consistency groups between volumes
● Intelligently understand devices that use the concept of storage
pools
● Scheduling local storage on Compute Nodes*

13. What are we missing:
If you’re deploying a Private Cloud with OpenStack (or considering
it)
● What do you need from Cinder that’s missing?
● What problems do you have with Cinder currently?
● How can we help make it easier, and more beneficial for you to
use?
DON’T HESITATE TO REACH OUT TO ME!!!

14. Get Involved:
Contributing to OpenStack isn’t just for developers
Open Source is more than just writing code
● Documentation
● Bug reports
● Feature requests
● Feedback, Feedback, Feedback
● Supporting others

15. Questions?
email: john.griffith@solidfire.com
twitter: @jdg_8
IRC: jgriffith