Cinder Block Storage Service project overview and update. Highlights from the Victoria release, state of the project, and planning for the Wallaby development cycle.

1. Cinder
Project overview and update
Brian Rosmaita
Principal Software Engineer, Red Hat
IRC: rosmaita
Twitter: @br14nr
12 November 2020

2. What does Cinder do?
• It’s the Block Storage service!
• Implement services and libraries to
provide on demand, self-service
access to Block Storage resources.
• Provide Software Defined Block
Storage via abstraction and
automation on top of various
traditional backend block storage
devices.

3. What does the Cinder project do?
● produces software in the following
repositories:
○ cinder
○ os-brick
○ python-cinderclient
○ python-brick-cinderclient-ext
○ cinder-tempest-plugin
○ cinderlib

4. Who does it?
● Founded during the Folsom
release of OpenStack
● 124 contributors in Train
○ from 42 companies
● 97 contributors in Ussuri
○ from 31 companies
● 77 contributors in Victoria
○ from 25 companies
The Cinder team at the Wallaby (Virtual) Project Team Gathering
26-30 October 2020

5. Who does it?
Red Hat 38.8%
Dell EMC 22.1%
Inspur 6.9%
NEC 5.9%
Mirantis 5.1%

6. ● Deployed in 86% of production
deployments
○ n = 331
○ Nova: 90%
● Deployed in 73% of testing/PoC
deployments
○ n = 102
○ Nova: 75%
Latest User Survey Numbers

7. Why are we looking at the horse’s back end?
● Well, your block storage has to actually be
stored somewhere … so storage backends are
essential to Cinder
● Cinder supports different backends through
drivers
○ Drivers mediate between the Block
Storage API, which provides a consistent
interface to users, and particular
backends where data is actually stored

8. ● Volume drivers: 79
○ 7 of these are “unsupported”
● Backup drivers: 6
○ 1 is “unsupported” and will be removed in
Wallaby (IBM TSM)
● FibreChannel Zone Manager drivers: 2
○ 1 is “unsupported”
The Backend Drivers
duckduckgo: All About Cinder Drivers

9. What is an “unsupported” driver?
● All Cinder drivers must run Third Party CI systems that test proposed
patches against an OpenStack environment connected to the vendor’s
backend
○ CIs must report on every patch, whether the change is in their own driver
or not
● If no CI reporting occurs within a two week span (or other issues are
found and not addressed in timely manner), the driver is marked
‘unsupported’

10. What is an “unsupported” driver?
● If a driver is ‘unsupported’ at the time of release, an operator must set
a specific configuration option in order to use the driver
● The driver is eligible for removal in the next development cycle
○ Since January 2020, the Cinder team will allow an ‘unsupported’ driver to
stay in-tree as long as they continue to pass OpenStack CI testing
○ Our experience has been that most vendors address driver issues
eventually, and dropping drivers and then restoring them was very
inconvenient for operators

11. What tests are the 3rd Party CIs running?
● The OpenStack integration test suite (“tempest”)
○ … but with Cinder configured to use the vendor’s hardware
● Additional cinder-focused API and scenario tests contained in the
cinder-tempest-plugin
○ We can add extra integration tests for drivers to focus on
particular areas of functionality for particular configurations
○ example: review . opendev . org / 737380

12. Cinder driver re-use for container PVs
ember-csi
(uses cinderlib)
cinder-csi-plugin

13. So, what’s new in Victoria?
● microversion 3.61 adds cluster_name to the
volume-detail response when called in an administrative
context
● microversion 3.62 adds a Default Volume Types API that
allows management of a default volume type for any
project
● improved handling of the Cinder default volume type
(has been backported to Ussuri 16.2.0 and Train 15.4.0 to
keep the behavior consistent)

14. So, what’s new in Victoria?
● Zstandard compression support added to the cinder
backup service (default is still Deflate (zlib))
● new drivers:
○ Dell EMC PowerStore (iSCSI, FC)
○ Hitachi HSBD (iSCSI, FC)
● many volume drivers have added features beyond the
Cinder required features (see the Victoria Release Notes)

15. Security Issues Addressed
● OSSN-0086, “Dell EMC ScaleIO/VxFlex OS Backend
Credentials Exposure”
○ Vulnerability fixed during Victoria development
○ Backported to Queens
● OSSN-0085, “Cinder configuration option can leak secret
key from Ceph backend”
○ only applies if using the rbd_keyring_conf option
with Ceph
○ the option has been removed in Victoria
“We are not amused.”

16. Upgrade-to-Ussuri Issue
● Bug #1893107 was discovered during the Victoria
development cycle (but does not affect Victoria)
○ If you already successfully upgraded Train->Ussuri, nothing
to worry about
○ If you started with Train, nothing to worry about
● If you upgraded Stein -> Train 15.3.0 or earlier and did
not purge your cinder database before the upgrade, you
should read the release notes for Cinder 15.4.0 and
Cinder 16.2.0
○ your upgrade path from Train to Ussuri may require some
actions in your Train deployment before you upgrade

17. So, what’s planned for Wallaby?
● Remove version 2 of the Block Storage API
○ was deprecated in Pike
○ version 3.0 is “just like” 2.0
● some new drivers
○ Open-E JovianDSS (merged)
○ Ceph iSCSI
○ Kioxia KumoScale
● “Consistent and Secure Policies”
● various internal improvements
Photo by JJ Harrison, CC BY-SA 3.0

18. So, what’s planned for Wallaby?
Summary of the Cinder Wallaby PTG sessions:
wiki . openstack . org / wiki / CinderWallabyPTGSummary
Photo by JJ Harrison, CC BY-SA 3.0
To contact the Cinder team:
tiny . cc / cinder-info

19. Get involved!
● The Cinder documentation could use an analysis by
a good information architect
● Make your backend vendors aware that you value
Cinder Third Party CI on their drivers
● Add tests to cinder-tempest-plugin if you are so
inclined
● “10 ways to contribute to an open source project
without writing code” by Heiko W. Rupp
○ tiny . cc / 10-ways
Photo by JJ Harrison, CC BY-SA 3.0
(sign not in original photo)
HELP
WANTED

20. @OpenStack
THANKS.
Questions?
openstack openstack OpenStackFoundation