Quick update of the OpenStack Cinder project, but mostly a discussion of open source software development opportunities working with the OpenStack Block Storage service. Presented at the OpenInfra Q3 Meetup in China on 26 September 2020.
1. Cinder
OpenInfra Meetup Q3 China
Brian Rosmaita
Cinder Project Team Leader
Senior Software Engineer, Red Hat
IRC: rosmaita
Twitter: @br14nr
26 September 2020
4. OpenStack is an open source project for building a private
or public infrastructure-as-a-service cloud running on
standard hardware
● Uses virtualized resources to build a cloud
● Relies on virtualization software
● Relies on a base operating system
● more info: openstack . org
5. What is a cloud?
Five "essential characteristics" (NIST special publication 800-145)
● on-demand self-service
● broad network access
● resource pooling ("multitenancy")
● rapid elasticity
● measured service
6. OpenStack architecture
The OpenStack architecture is a number of projects that provide different
cloud services via REST APIs.
● Compute Service - Nova
● Networking Service - Neutron
● Image Service - Glance
● Block Storage Service - Cinder
● Identity Service - Keystone
● Object Store - Swift
Search: openstack api reference
8. OpenStack architecture
Each Service has an associated Project Team that is responsible for
maintaining that service and all its associated deliverables.
● Anyone can be part of the Project Team, you just need to participate
● Each team has a group of core reviewers who have the responsibility of
maintaining project stability and focus
○ Who is in this group is decided by the Project Team
12. OpenStack PTG
● Where the design discussions and planning for the next release happen
● Next release: “Wallaby”
● The Wallaby PTG will be a virtual event
● October 26-30, 2020
● info: openstack . org / ptg
14. OpenStack Releases
● releases . openstack . org
● Unified release cadence is every 6 months
○ Each project makes a Release candidate 3 weeks before release
○ a new stable branch is cut
○ master becomes the new development branch
● Releases from stable branches happen … whenever
○ these are done per-project, no unified coordination
○ usually 3 “releasable” branches open
○ others in “extended maintenance” mode (no releases)
15. OpenStack Releases
● Release name is selected by the OpenStack community
○ Must start with a letter of the ISO basic Latin alphabet, following the
initial letter of the previous release, beginning with ‘A’ and rotating
back to ‘A’ after a ‘Z’ release
○ Must be composed of the 26 letters of ISO basic Latin; names that
can be transliterated into this character set are also acceptable
■ the last release was ‘Ussuri’ (乌苏里)
○ Must be a single word of no more than 10 characters
16. OpenStack Releases
● The coordinated release is referred to by the release name
○ Each individual project has its own version number
○ Nova, the oldest project, will release version 22.0.0 for Victoria
○ Cinder first appeared in the Folsom release, so it will release version 17.0.0
for Victoria
● After the coordinated release, the projects are on their own to make
releases as they see necessary to address critical bugs or security issues
○ example: train
■ nova: start 20.0.0, most recent 20.4.0
■ glance: start 19.0.0, most recent 19.0.4
■ cinder: start 15.0.0, most recent 15.3.0
■ keystone: start 16.0.0, most recent 16.0.1
17. OpenStack Distributions
● It’s a lot easier to consume OpenStack from a distribution, which
does all the work of keeping the code up to date and tests it on a
particular platform
● For example,
(please excuse the shameless plug for my employer)
18.
19. What does Cinder do?
• 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.
20. Where is the code?
opendev . org / openstack / <name>
● Mirrored on github
21. What are the repository names?
I’m going to answer this indirectly
cinder . openstack . org / contributor
Take the first link:
So You Want to Contribute ...
22. What are the repository names?
● cinder
● python-cinderclient
● os-brick
● python-brick-cinderclient-ext
● cinderlib
● cinder-tempest-plugin
● cinder-specs
23. 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
24. Cinder backend drivers
● There are over 70 drivers in the cinder code
repository
● ‘Supported’ drivers have functioning
third-party CI systems that run on every
proposed patch to cinder
● The 3rd party CI provides additional
information when patches are reviewed
26. How code gets into OpenStack
● Clone the code repository with git
● Make your changes in a local branch
● Submit your change to gerrit
○ gerrit assigns a “Change-Id” to your patch
○ it creates a branch with your patch applied to it
○ it maintains a history of your submissions with the same
Change-Id
■ this allows reviewers to compare changes to different
versions of the patch
27. How code gets into OpenStack
● If you want to look at a real-life gerrit review:
○ review . opendev . org / 730183
28.
29.
30. How code gets into OpenStack
● One nice thing about using gerrit is that if you’re tracking down a bug,
you can find out from git what commit added the problematic code,
and the commit message will contain the gerrit Change-Id
● You can go back to the original review and follow the discussion to
understand why the change was made the way it was
31.
32.
33.
34.
35. What tests are the 3rd Party CIs running?
● The OpenStack integration test suite (“tempest”)
● 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
36. Software development opportunities
● If you work for a storage vendor, you might be interested in
contributing a new backend driver
● If you use an existing open source storage solution (for example,
Ceph), you might be interested in helping to maintain the rbd driver
● If you have run into a bug, you might be interested in contributing
code to the cinder-tempest-plugin to make sure there’s not a
regression (or to demonstrate the bug in other drivers)
● The python-cinderclient can always use some love
○ or you could work on integration with the openstackclient
38. What about containers?
● Glad you asked!
● As mentioned earlier, Cinder has over 70 backend drivers that are
tested all the time through the cinder 3rd party CI systems
○ it would be nice if they could be used to help provide persistent
storage for containers
○ well, they can!
39. Container Storage Interface
● Specifies an interface to enable a storage
vendor to develop a single plugin that will
work across all container systems
supporting the standard
● Storage vendors do not have to touch the
core code of the container orchestration
system
40. Cinder and the CSI
● There are three common methods for using cinder code with a
container orchestration system
○ Use the cinder-csi-plugin
○ If you’re running kubernetes on top of OpenStack, and your
OpenStack deployment contains Cinder (as about 98% of
deployments do), the cinder-csi-plugin can serve persistent
volumes from whatever backends are configured for Cinder
■ kubernetes code
■ github . com / kubernetes / cloud-provider-openstack
41. Cinder and the CSI
● If you’re not running kubernetes on top of OpenStack, you can still
use the cinder-csi-plugin and have Cinder manage your persistent
volumes by running Cinder in “standalone” mode
○ OpenSDS takes this approach
○ advantage: gives you a wide choice of storage backends, namely,
whatever Cinder supports
○ disadvantage: very heavyweight
42. Cinder and the CSI
● meet cinderlib
○ a python library that allows cinder storage drivers to be used
outside of Cinder
○ a deliverable of the OpenStack cinder project
○ removes the DBMS, message broker, Block Storage API,
scheduler, and volume manager layers from cinder
○ code: opendev . org / openstack / cinderlib
43. Cinder and the CSI
● cinderlib has been available since the Stein release of OpenStack
○ it’s on a “cycle-trailing” release schedule
○ victoria cinderlib is scheduled to be released on or before 15
January 2021
○ current versions
■ stein: 0.9.0
■ train: 1.0.1
■ ussuri: 2.0.0
44. Cinder and the CSI
● cinderlib allows you to take advantage of all the tested driver code
from the Cinder project
● cinderlib allows storage vendors to re-use the driver code that they
have developed for Cinder
45. Cinder and the CSI
● Ember CSI
● provides a CSI standard interface
to cinderlib
● code: ember-csi . io
46.
47. So what’s up with Cinder?
● Not a lot of new features these days
● Mostly stability improvements
● Cinder grew really fast for a while, and added some features that we
are still catching up with from a testing point of view
○ contribute to cinder-tempest-plugin!
● Vendors continue to add new drivers
48. volume-local-cache
● a “stealth feature” in the victoria release
○ it’s not being announced
● still requires work on the compute side before it can be a real feature
● … and documentation
● design document:
○ specs . openstack . org / openstack / cinder-specs /
○ (look under the Victoria specs)