These are the slides presented during the Berlin OpenStack Summit. The presentation includes information about the Cinder Team and our processes. Intended to help new contributors to get involved developing with the team upstream.
5. 5
● Provides persistent
block storage
resources for an
OpenStack cloud.
● Supports multiple back-
ends. Approximately 70
volume drivers in tree.
Cinder Overview
6. 6
Vendor Backends
● Drivers from many different vendors
● Different protocols used depending on the driver
○ iSCSI
○ Fibre Channel
○ RBD
○ RemoteFS
○ Etc.
9. 9
Cinder’s Team
● PTL
○ Jay Bryant (jungleboyj)
● Core Team
○ Sean McGinnis (smcginnis)
○ Walt Boring (hemna)
○ TommyLike Hu
○ Gorka Eguileor (geguileo)
○ John Griffith (jgriffith)
○ Eric Harney (eharney)
○ Ivan Kolodyazhny (e0ne)
○ Xing Yang (Xyang)
11. 11
Upstream Institute - Key Info
● VM image to get your development started
● OpenStack account setup
○ https://docs.openstack.org/upstream-training/workflow-reg-and-
accounts.html
● Launchpad/Storyboard introduction
○ https://docs.openstack.org/upstream-training/workflow-task-
tracking.html
● Workflow introduction
○ https://docs.openstack.org/upstream-training/workflow-training-
contribution-process.html
● Introduction to gerrit and code reviews
○ https://docs.openstack.org/upstream-training/workflow-gerrit.html
○ https://docs.openstack.org/upstream-training/workflow-reviewing.html
15. 15
Cinder Specs
● https://github.com/openstack/cinder-specs
● We request specs for more complicated changes
● Organized by release (specs/<release>)
● Template from which to start: specs/template.rst
● Before pushing your spec run ‘tox -e docs,py27,pep8’
○ Look for any errors and please correct before pushing
for review
16. 16
IRC and Cinder Meetings
● #openstack-cinder
○ Please join us for all things Cinder
○ Try @? for some (╯°□°)╯︵ ┻━┻ fun
● Weekly Meeting
○ Wednesdays at 16:00 UTC
○ #openstack-meeting
○ https://wiki.openstack.org/wiki/CinderMeetings
○ Add agenda items with your IRC nickname to the
meeting agenda/notes etherpad
17. 17
Typical Development Cycle
● Stein release schedule
○ https://releases.openstack.org/stein/schedule.html
● Milestone 2
○ Spec freeze
○ New driver merge deadline
● Milestone 3
○ New feature freeze
○ Move focus to testing and bug fixes
○ Need 3rd party CI’s functional to avoid addition of unsupported flag
● RC
○ Bug fixes only
● Some flexibility around dates allowed with core team and PTL’s discretion
18. 18
3rd Party CI
● 3rd Party CI is required for all Cinder drivers
○ https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
● Purpose
○ To ensure that a vendor’s driver functions properly as changes merge to
the Cinder tree
○ To show that patches against a vendor’s driver work
● Policy (Proposed)
○ 3rd Party CI must run successfully against a weekly job executed to test
that CI’s are reporting
○ 3rd Party CI must fail a job submitted that should fail all 3rd Party CI
testing.
○ A vendor CI that doesn’t meet these requirements during a release
cycle is marked ‘Unsupported’ and consumers have to update their
configs to indicate they wish to run an unsupported driver
○ Continued non-compliance results in driver removal in the next release.
19. 19
3rd Party CI - Review Implications
● If a patch fails all CI’s, something is
wrong
● Patches against a driver must pass
the vendor’s CI before being
merged
20. 20
About Reviews
● We need your help!
● Good way to get involved with Cinder
○ Learn the code and the project organization
○ Don’t need to know how Cinder works to catch logic errors and typos
● Gets you visibility to the Cinder team
● Review inboxes:
○ Cinder review inbox
○ os-brick review inbox
○ python-brick-cinderclient-ex review inbox
● Track how we are doing:
○ http://cinderstats.ivehearditbothways.com/
21. 21
Cinder Code Layout - Top Level
● api-ref -- Source documentation for v1,2 and 3 Cinder API
● cinder -- Cinder’s source directory with high level implementations at the top
level (i.e. exceptions, i18n, policy, utils, etc.)
● doc -- Developer documentation that is published to the OpenStack website
● etc -- Config files that are not automatically generated
● rally-jobs -- Rally tasks and plugins to be run by OpenStack CI
● releasenotes -- Contains release notes for patches
● tools -- Config generation script, driver list generation, etc.
22. 22
Cinder Code Layout - /cinder
● api -- v1, 2, 3 and API extension implementation
● backup -- Backup driver API and implementations
● brick -- Legacy brick directory, mostly migrated to os-brick library
● cmd -- Starter scripts for Cinder’s processes (api, scheduler, volume, etc.)
● common -- Shared files for config, sqlalchemy, etc.
● compute -- Source for interfacing with Nova
● config -- Source files for config file generator
● consistencygroup -- Consistency Group API implementation
● db -- sqlalchemy migration scripts and DB API implementation
23. 23
Cinder Code Layout - /cinder (cont.)
● group -- Generic Group API implementation
● hacking -- Hacking check implementation
● image -- Source for interfacing with Glance
● interface -- Base interface definition for driver validation and reference
● keymgr -- Simple security key implementation
● locale -- Translation files for log messages
● message -- User message API implementation
● objects -- Implementation of Cinder’s Oslo Versioned Objects
● scheduler -- Scheduling option implementations
● tests -- Compliance, functional, tempest and unit test implementation
● transfer -- API implementation of volume transfer
● volume -- Implementation of API and drivers for volumes
● wsgi -- Cinder Web Server Gateway Interface implementation
● zonemanager -- Fibre Channel Zonemanager implementation
24. 24
Release Notes
● Developer’s way to communicate to the end user
● Most important for changes that impact Cinder’s functionality
● Documents:
○ Security issue fixes,
○ New features
○ Upgrade notes
○ Known issues
○ Deprecation notes
● Not required for every change, but important for anything that directly
impacts packagers or users
25. 25
Tox Tests
● Tox is a test runner used by most OpenStack projects
● Many of the same test targets, but a few specific to Cinder
● Before submitting a patch, best to at least run py27 and pep8 targets
(tox -e py27,fast8)
py27, py35 Runs unit tests using either Python 2.7 or 3.5
genopts Must be run when adding any new config options to regenerate opts.py file
used to create the sample config
pep8, fast8 Runs code checks to make sure it conforms to coding style and hacking
checks to look for specific conditions
releasenotes Validates new release notes (must commit first!)
compliance Useful for driver developers, will validate all required driver interfaces are
implemented
26. Q & A
Twitter & IRC: JungleboyJ
E-mail: jsbryant@electronicjungle.net