Essentials (tl;dr)

This chapter presents essential information that every Ceph developer needs to know.

Leads

The Ceph project is led by Sage Weil. In addition, each major project component has its own lead. The following table shows all the leads and their nicks on GitHub:

Scope	Lead	GitHub nick
Ceph	Sage Weil	liewegas
RADOS	Neha Ojha	neha-ojha
RGW	Yehuda Sadeh	yehudasa
RGW	Matt Benjamin	mattbenjamin
RBD	Ilya Dryomov	dis
CephFS	Patrick Donnelly	batrick
Dashboard	Ernesto Puerta	epuertat
MON	Joao Luis	jecluis
Build/Ops	Ken Dreyer	ktdreyer
Docs	Zac Dover	zdover23

The Ceph-specific acronyms in the table are explained in Architecture.

History

See the History chapter of the Wikipedia article.

Licensing

Ceph is free software.

Unless stated otherwise, the Ceph source code is distributed under the terms of the LGPL2.1 or LGPL3.0. For full details, see the file COPYING in the top-level directory of the source-code tree.

Source code repositories

The source code of Ceph lives on GitHub in a number of repositories below the Ceph "organization".

A working knowledge of git is essential to make a meaningful contribution to the project as a developer.

Although the Ceph "organization" includes several software repositories, this document covers only one: https://github.com/ceph/ceph.

Redmine issue tracker

Although GitHub is used for code, Ceph-related issues (Bugs, Features, Backports, Documentation, etc.) are tracked at http://tracker.ceph.com, which is powered by Redmine.

The tracker has a Ceph project with a number of subprojects loosely corresponding to the various architectural components (see Architecture).

Mere registration in the tracker automatically grants permissions sufficient to open new issues and comment on existing ones.

To report a bug or propose a new feature, jump to the Ceph project and click on New issue.

Mailing lists

Ceph Development Mailing List

The dev@ceph.io list is for discussion about the development of Ceph, its interoperability with other technology, and the operations of the project itself.

The email discussion list for Ceph development is open to all. Subscribe by sending a message to dev-request@ceph.io with the following line in the body of the message:

subscribe ceph-devel

Ceph Client Patch Review Mailing List

The ceph-devel@vger.kernel.org list is for discussion and patch review for the Linux kernel Ceph client component. Note that this list used to be an all-encompassing list for developers. When searching the archives, remember that this list contains the generic devel-ceph archives before mid-2018.

Subscribe to the list covering the Linux kernel Ceph client component by sending a message to majordomo@vger.kernel.org with the following line in the body of the message:

subscribe ceph-devel

Other Ceph Mailing Lists

There are also other Ceph-related mailing lists.

IRC

In addition to mailing lists, the Ceph community also communicates in real time using Internet Relay Chat.

The Ceph community gathers in the #ceph channel of the Open and Free Technology Community (OFTC) IRC network.

Created in 1988, Internet Relay Chat (IRC) is a relay-based, real-time chat protocol. It is mainly designed for group (many-to-many) communication in discussion forums called channels, but also allows one-to-one communication via private message. On IRC you can talk to many other members using Ceph, on topics ranging from idle chit-chat to support questions. Though a channel might have many people in it at any one time, they might not always be at their keyboard; so if no-one responds, just wait around and someone will hopefully answer soon enough.

Registration

If you intend to use the IRC service on a continued basis, you are advised to register an account. Registering gives you a unique IRC identity and allows you to access channels where unregistered users have been locked out for technical reasons.

Channels

To connect to the OFTC IRC network, download an IRC client and configure it to connect to irc.oftc.net. Then join one or more of the channels. Discussions inside #ceph are logged and archives are available online.

Here are the real-time discussion channels for the Ceph community:

#ceph

#ceph-devel

#cephfs

#ceph-dashboard

#ceph-orchestrators

#sepia

Submitting patches

The canonical instructions for submitting patches are contained in the file CONTRIBUTING.rst in the top-level directory of the source-code tree. There may be some overlap between this guide and that file.

All newcomers are encouraged to read that file carefully.

Building from source

See instructions at Build Ceph.

Using ccache to speed up local builds

ccache can make the process of rebuilding the ceph source tree faster.

Before you use ccache to speed up your rebuilds of the ceph source tree, make sure that your source tree is clean and will produce no build failures. When you have a clean source tree, you can confidently use ccache, secure in the knowledge that you're not using a dirty tree.

Old build artifacts can cause build failures. You might introduce these artifacts unknowingly when switching from one branch to another. If you see build errors when you attempt a local build, follow the procedure below to clean your source tree.

Cleaning the Source Tree

ninja clean

备注

The following commands will remove everything in the source tree that isn't tracked by git. Make sure to back up your log files and configuration options before running these commands.

git clean -fdx; git submodule foreach git clean -fdx

Building Ceph with ccache

ccache is available as a package in most distros. To build ceph with ccache, run the following command.

cmake -DWITH_CCACHE=ON ..

Using ccache to Speed Up Build Times

ccache can be used for speeding up all builds of the system. For more details, refer to the run modes section of the ccache manual. The default settings of ccache can be displayed with the ccache -s command.

备注

We recommend overriding the max_size. The default is 10G. Use a larger value, like 25G. Refer to the configuration section of the ccache manual for more information.

To further increase the cache hit rate and reduce compile times in a development environment, set the version information and build timestamps to fixed values. This makes it unnecessary to rebuild the binaries that contain this information.

This can be achieved by adding the following settings to the ccache configuration file ccache.conf:

sloppiness = time_macros
run_second_cpp = true

Now, set the environment variable SOURCE_DATE_EPOCH to a fixed value (a UNIX timestamp) and set ENABLE_GIT_VERSION to OFF when running cmake:

export SOURCE_DATE_EPOCH=946684800
cmake -DWITH_CCACHE=ON -DENABLE_GIT_VERSION=OFF ..

备注

Binaries produced with these build options are not suitable for production or debugging purposes, as they do not contain the correct build time and git version information.

Development-mode cluster

See Developer Guide (Quick).

Kubernetes/Rook development cluster

See Hacking on Ceph in Kubernetes with Rook

Backporting

All bugfixes should be merged to the master branch before being backported. To flag a bugfix for backporting, make sure it has a tracker issue associated with it and set the Backport field to a comma-separated list of previous releases (e.g. "hammer,jewel") that you think need the backport. The rest (including the actual backporting) will be taken care of by the Stable Releases and Backports team.

Guidance for use of cluster log

If your patches emit messages to the Ceph cluster log, please consult this: Use of the cluster log.