5 You can help the Ceph project by contributing to the documentation. Even
6 small contributions help the Ceph project, such as fixing
7 spelling errors or rewriting confusing instructions.
9 The easiest way to suggest a correction to the documentation is to send an
10 email to `ceph-users@ceph.io`. Include the string "ATTN: DOCS" or
11 "Attention: Docs" or "Attention: Documentation" in the subject line. In
12 the body of the email, include the text to be corrected (so that I can find
13 it in the repo) and include your correction.
15 Another way to suggest a documentation correction is to make a pull request.
16 The instructions for making a pull request against the Ceph documentation are
17 in the section :ref:`making_contributions`.
19 If this is your first time making an improvement to the documentation or
20 if you have noticed a small mistake (such as a spelling error or a typo),
21 it will be easier to send an email than to make a pull request. You will
22 be credited for the improvement unless you instruct Ceph Upstream
23 Documentation not to credit you.
25 Location of the Documentation in the Repository
26 ===============================================
28 The Ceph documentation source is in the ``ceph/doc`` directory of the Ceph
29 repository. Python Sphinx renders the source into HTML and manpages.
31 Viewing Old Ceph Documentation
32 ==============================
33 The https://docs.ceph.com link displays the latest release branch by default
34 (for example, if "Quincy" is the most recent release, then by default
35 https://docs.ceph.com displays the documentation for Quincy), but you can view
36 the documentation for older versions of Ceph (for example, ``pacific``) by
37 replacing the version name in the url (for example, ``quincy`` in
38 `https://docs.ceph.com/en/pacific <https://docs.ceph.com/en/quincy>`_) with the
39 branch name you prefer (for example, ``pacific``, to create a URL that reads
40 `https://docs.ceph.com/en/pacific/ <https://docs.ceph.com/en/pacific/>`_).
42 .. _making_contributions:
47 Making a documentation contribution involves the same basic procedure as making
48 a code contribution, with one exception: you must build documentation source
49 instead of compiling program source. This sequence (the sequence of building the documentation source) includes the following steps:
54 #. `Build the Source`_
55 #. `Commit the Change`_
57 #. `Make a Pull Request`_
63 Ceph documentation lives in the Ceph repository right alongside the Ceph source
64 code under the ``ceph/doc`` directory. For details on github and Ceph,
65 see :ref:`Get Involved`.
67 The most common way to make contributions is to use the `Fork and Pull`_
70 #. Install git locally. For Debian/Ubuntu, execute:
74 sudo apt-get install git
82 For CentOS/RHEL, execute:
88 #. Ensure your ``.gitconfig`` file has your name and email address. :
93 email = {your-email-address}
100 git config --global user.name "John Doe"
101 git config --global user.email johndoe@example.com
104 #. Create a `github`_ account (if you don't have one).
106 #. Fork the Ceph project. See https://github.com/ceph/ceph.
108 #. Clone your fork of the Ceph project to your local host.
111 Ceph organizes documentation into an information architecture primarily by its
114 - **Ceph Storage Cluster:** The Ceph Storage Cluster documentation resides
115 under the ``doc/rados`` directory.
117 - **Ceph Block Device:** The Ceph Block Device documentation resides under
118 the ``doc/rbd`` directory.
120 - **Ceph Object Storage:** The Ceph Object Storage documentation resides under
121 the ``doc/radosgw`` directory.
123 - **Ceph File System:** The Ceph File System documentation resides under the
124 ``doc/cephfs`` directory.
126 - **Installation (Quick):** Quick start documentation resides under the
127 ``doc/start`` directory.
129 - **Installation (Manual):** Manual installation documentation resides under
130 the ``doc/install`` directory.
132 - **Manpage:** Manpage source resides under the ``doc/man`` directory.
134 - **Developer:** Developer documentation resides under the ``doc/dev``
137 - **Images:** If you include images such as JPEG or PNG files, you should
138 store them under the ``doc/images`` directory.
144 When you make small changes to the documentation, such as fixing typographical
145 errors or clarifying explanations, use the ``main`` branch (default). You
146 should also use the ``main`` branch when making contributions to features that
147 are in the current release. ``main`` is the most commonly used branch. :
153 When you make changes to documentation that affect an upcoming release, use
154 the ``next`` branch. ``next`` is the second most commonly used branch. :
160 When you are making substantial contributions such as new features that are not
161 yet in the current release; if your contribution is related to an issue with a
162 tracker ID; or, if you want to see your documentation rendered on the Ceph.com
163 website before it gets merged into the ``main`` branch, you should create a
164 branch. To distinguish branches that include only documentation updates, we
165 prepend them with ``wip-doc`` by convention, following the form
166 ``wip-doc-{your-branch-name}``. If the branch relates to an issue filed in
167 http://tracker.ceph.com/issues, the branch name incorporates the issue number.
168 For example, if a documentation branch is a fix for issue #4000, the branch name
169 should be ``wip-doc-4000`` by convention and the relevant tracker URL will be
170 http://tracker.ceph.com/issues/4000.
172 .. note:: Please do not mingle documentation contributions and source code
173 contributions in a single commit. When you keep documentation
174 commits separate from source code commits, it simplifies the review
175 process. We highly recommend that any pull request that adds a feature or
176 a configuration option, should also include a documentation commit,
177 describing the relevant changes/options.
179 Before you create your branch name, ensure that it doesn't already exist in the
180 local or remote repository. :
184 git branch -a | grep wip-doc-{your-branch-name}
186 If it doesn't exist, create your branch:
190 git checkout -b wip-doc-{your-branch-name}
196 Modifying a document involves opening a reStructuredText file, changing
197 its contents, and saving the changes. See `Documentation Style Guide`_ for
198 details on syntax requirements.
200 Adding a document involves creating a new reStructuredText file within the
201 ``doc`` directory tree with a ``*.rst``
202 extension. You must also include a reference to the document: a hyperlink
203 or a table of contents entry. The ``index.rst`` file of a top-level directory
204 usually contains a TOC, where you can add the new file name. All documents must
205 have a title. See `Headings`_ for details.
207 Your new document doesn't get tracked by ``git`` automatically. When you want
208 to add the document to the repository, you must use ``git add
209 {path-to-filename}``. For example, from the top level directory of the
210 repository, adding an ``example.rst`` file to the ``rados`` subdirectory would
215 git add doc/rados/example.rst
217 Deleting a document involves removing it from the repository with ``git rm
218 {path-to-filename}``. For example:
222 git rm doc/rados/example.rst
224 You must also remove any reference to a deleted document from other documents.
230 To build the documentation, navigate to the ``ceph`` repository directory:
238 The directory that contains ``build-doc`` and ``serve-doc`` must be included
239 in the ``PATH`` environment variable in order for these commands to work.
242 To build the documentation on Debian/Ubuntu, Fedora, or CentOS/RHEL, execute:
248 To scan for the reachability of external links, execute:
252 admin/build-doc linkcheck
254 Executing ``admin/build-doc`` will create a ``build-doc`` directory under
255 ``ceph``. You may need to create a directory under ``ceph/build-doc`` for
256 output of Javadoc files:
260 mkdir -p output/html/api/libcephfs-java/javadoc
262 The build script ``build-doc`` will produce an output of errors and warnings.
263 You MUST fix errors in documents you modified before committing a change, and
264 you SHOULD fix warnings that are related to syntax you modified.
266 .. important:: You must validate ALL HYPERLINKS. If a hyperlink is broken,
267 it automatically breaks the build!
269 Once you build the documentation set, you may start an HTTP server at
270 ``http://localhost:8080/`` to view it:
276 You can also navigate to ``build-doc/output`` to inspect the built documents.
277 There should be an ``html`` directory and a ``man`` directory containing
278 documentation in HTML and manpage formats respectively.
280 Build the Source (First Time)
281 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
283 Ceph uses Python Sphinx, which is generally distribution agnostic. The first
284 time you build Ceph documentation, it will generate a doxygen XML tree, which
285 is a bit time consuming.
287 Python Sphinx does have some dependencies that vary across distributions. The
288 first time you build the documentation, the script will notify you if you do not
289 have the dependencies installed. To run Sphinx and build documentation successfully,
290 the following packages are required:
294 <style type="text/css">div.body h3{margin:5px 0px 0px 0px;}</style>
295 <table cellpadding="10"><colgroup><col width="30%"><col width="30%"><col width="30%"></colgroup><tbody valign="top"><tr><td><h3>Debian/Ubuntu</h3>
311 </td><td><h3>Fedora</h3>
329 </td><td><h3>CentOS/RHEL</h3>
346 </td></tr></tbody></table>
349 Install each dependency that is not installed on your host. For Debian/Ubuntu
350 distributions, execute the following:
354 sudo apt-get install gcc python-dev python-pip libxml2-dev libxslt-dev doxygen graphviz ant ditaa
355 sudo apt-get install python-sphinx
357 For Fedora distributions, execute the following:
361 sudo yum install gcc python-devel python-pip libxml2-devel libxslt-devel doxygen graphviz ant
362 sudo pip install html2text
363 sudo yum install python-jinja2 python-pygments python-docutils python-sphinx
364 sudo yum install jericho-html ditaa
366 For CentOS/RHEL distributions, it is recommended to have ``epel`` (Extra
367 Packages for Enterprise Linux) repository as it provides some extra packages
368 which are not available in the default repository. To install ``epel``, execute
373 sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
375 For CentOS/RHEL distributions, execute the following:
379 sudo yum install gcc python-devel python-pip libxml2-devel libxslt-devel doxygen graphviz ant
380 sudo pip install html2text
382 For CentOS/RHEL distributions, the remaining python packages are not available
383 in the default and ``epel`` repositories. So, use http://rpmfind.net/ to find
384 the packages. Then, download them from a mirror and install them. For example:
388 wget http://rpmfind.net/linux/centos/7/os/x86_64/Packages/python-jinja2-2.7.2-2.el7.noarch.rpm
389 sudo yum install python-jinja2-2.7.2-2.el7.noarch.rpm
390 wget http://rpmfind.net/linux/centos/7/os/x86_64/Packages/python-pygments-1.4-9.el7.noarch.rpm
391 sudo yum install python-pygments-1.4-9.el7.noarch.rpm
392 wget http://rpmfind.net/linux/centos/7/os/x86_64/Packages/python-docutils-0.11-0.2.20130715svn7687.el7.noarch.rpm
393 sudo yum install python-docutils-0.11-0.2.20130715svn7687.el7.noarch.rpm
394 wget http://rpmfind.net/linux/centos/7/os/x86_64/Packages/python-sphinx-1.1.3-11.el7.noarch.rpm
395 sudo yum install python-sphinx-1.1.3-11.el7.noarch.rpm
397 Ceph documentation makes extensive use of `ditaa`_, which is not presently built
398 for CentOS/RHEL7. You must install ``ditaa`` if you are making changes to
399 ``ditaa`` diagrams so that you can verify that they render properly before you
400 commit new or modified ``ditaa`` diagrams. You may retrieve compatible required
401 packages for CentOS/RHEL distributions and install them manually. To run
402 ``ditaa`` on CentOS/RHEL7, following dependencies are required:
408 Use http://rpmfind.net/ to find compatible ``ditaa`` and the dependencies.
409 Then, download them from a mirror and install them. For example:
413 wget http://rpmfind.net/linux/fedora/linux/releases/22/Everything/x86_64/os/Packages/j/jericho-html-3.3-4.fc22.noarch.rpm
414 sudo yum install jericho-html-3.3-4.fc22.noarch.rpm
415 wget http://rpmfind.net/linux/centos/7/os/x86_64/Packages/jai-imageio-core-1.2-0.14.20100217cvs.el7.noarch.rpm
416 sudo yum install jai-imageio-core-1.2-0.14.20100217cvs.el7.noarch.rpm
417 wget http://rpmfind.net/linux/centos/7/os/x86_64/Packages/batik-1.8-0.12.svn1230816.el7.noarch.rpm
418 sudo yum install batik-1.8-0.12.svn1230816.el7.noarch.rpm
419 wget http://rpmfind.net/linux/fedora/linux/releases/22/Everything/x86_64/os/Packages/d/ditaa-0.9-13.r74.fc21.noarch.rpm
420 sudo yum install ditaa-0.9-13.r74.fc21.noarch.rpm
422 Once you have installed all these packages, build the documentation by following
423 the steps given in `Build the Source`_.
429 Ceph documentation commits are simple, but follow a strict convention:
431 - A commit SHOULD have 1 file per commit (it simplifies rollback). You MAY
432 commit multiple files with related changes. Unrelated changes SHOULD NOT
433 be put into the same commit.
434 - A commit MUST have a comment.
435 - A commit comment MUST be prepended with ``doc:``. (strict)
436 - The comment summary MUST be one line only. (strict)
437 - Additional comments MAY follow a blank line after the summary,
439 - A commit MAY include ``Fixes: https://tracker.ceph.com/issues/{bug number}``.
440 - Commits MUST include ``Signed-off-by: Firstname Lastname <email>``. (strict)
442 .. tip:: Follow the foregoing convention particularly where it says
443 ``(strict)`` or you will be asked to modify your commit to comply with
446 The following is a common commit comment (preferred)::
448 doc: Fixes a spelling error and a broken hyperlink.
450 Signed-off-by: John Doe <john.doe@gmail.com>
453 The following comment includes a reference to a bug. ::
455 doc: Fixes a spelling error and a broken hyperlink.
457 Fixes: https://tracker.ceph.com/issues/1234
459 Signed-off-by: John Doe <john.doe@gmail.com>
462 The following comment includes a terse sentence following the comment summary.
463 There is a carriage return between the summary line and the description::
465 doc: Added mon setting to monitor config reference
467 Describes 'mon setting', which is a new setting added
470 Signed-off-by: John Doe <john.doe@gmail.com>
473 To commit changes, execute the following:
480 An easy way to manage your documentation commits is to use visual tools for
481 ``git``. For example, ``gitk`` provides a graphical interface for viewing the
482 repository history, and ``git-gui`` provides a graphical interface for viewing
483 your uncommitted changes, staging them for commit, committing the changes and
484 pushing them to your forked Ceph repository.
487 For Debian/Ubuntu, execute:
491 sudo apt-get install gitk git-gui
493 For Fedora/CentOS/RHEL, execute:
497 sudo yum install gitk git-gui
503 cd {git-ceph-repo-path}
506 Finally, select **File->Start git gui** to activate the graphical user interface.
512 Once you have one or more commits, you must push them from the local copy of the
513 repository to ``github``. A graphical tool like ``git-gui`` provides a user
514 interface for pushing to the repository. If you created a branch previously:
518 git push origin wip-doc-{your-branch-name}
530 As noted earlier, you can make documentation contributions using the `Fork and
538 In case The PR did not got a review within in a reasonable timeframe, please get in touch
539 with the corresponding component lead of the :ref:`clt`.
541 Documentation Style Guide
542 =========================
544 One objective of the Ceph documentation project is to ensure the readability of
545 the documentation in both native reStructuredText format and its rendered
546 formats such as HTML. Navigate to your Ceph repository and view a document in
547 its native format. You may notice that it is generally as legible in a terminal
548 as it is in its rendered HTML format. Additionally, you may also notice that
549 diagrams in ``ditaa`` format also render reasonably well in text mode. :
553 less doc/architecture.rst
555 Review the following style guides to maintain this consistency.
561 #. **Document Titles:** Document titles use the ``=`` character overline and
562 underline with a leading and trailing space on the title text line.
563 See `Document Title`_ for details.
565 #. **Section Titles:** Section tiles use the ``=`` character underline with no
566 leading or trailing spaces for text. Two carriage returns should precede a
567 section title (unless an inline reference precedes it). See `Sections`_ for
570 #. **Subsection Titles:** Subsection titles use the ``_`` character underline
571 with no leading or trailing spaces for text. Two carriage returns should
572 precede a subsection title (unless an inline reference precedes it).
578 As a general rule, we prefer text to wrap at column 80 so that it is legible in
579 a command line interface without leading or trailing white space. Where
580 possible, we prefer to maintain this convention with text, lists, literal text
581 (exceptions allowed), tables, and ``ditaa`` graphics.
583 #. **Paragraphs**: Paragraphs have a leading and a trailing carriage return,
584 and should be 80 characters wide or less so that the documentation can be
585 read in native format in a command line terminal.
587 #. **Literal Text:** To create an example of literal text (e.g., command line
588 usage), terminate the preceding paragraph with ``::`` or enter a carriage
589 return to create an empty line after the preceding paragraph; then, enter
590 ``::`` on a separate line followed by another empty line. Then, begin the
591 literal text with tab indentation (preferred) or space indentation of 3
594 #. **Indented Text:** Indented text such as bullet points
595 (e.g., ``- some text``) may span multiple lines. The text of subsequent
596 lines should begin at the same character position as the text of the
597 indented text (less numbers, bullets, etc.).
599 Indented text may include literal text examples. Whereas, text indentation
600 should be done with spaces, literal text examples should be indented with
601 tabs. This convention enables you to add an additional indented paragraph
602 following a literal example by leaving a blank line and beginning the
603 subsequent paragraph with space indentation.
605 #. **Numbered Lists:** Numbered lists should use autonumbering by starting
606 a numbered indent with ``#.`` instead of the actual number so that
607 numbered paragraphs can be repositioned without requiring manual
610 #. **Code Examples:** Ceph supports the use of the
611 ``.. code-block::<language>`` role, so that you can add highlighting to
612 source examples. This is preferred for source code. However, use of this
613 tag will cause autonumbering to restart at 1 if it is used as an example
614 within a numbered list. See `Showing code examples`_ for details.
617 Paragraph Level Markup
618 ----------------------
620 The Ceph project uses `paragraph level markup`_ to highlight points.
622 #. **Tip:** Use the ``.. tip::`` directive to provide additional information
623 that assists the reader or steers the reader away from trouble.
625 #. **Note**: Use the ``.. note::`` directive to highlight an important point.
627 #. **Important:** Use the ``.. important::`` directive to highlight important
628 requirements or caveats (e.g., anything that could lead to data loss). Use
629 this directive sparingly, because it renders in red.
631 #. **Version Added:** Use the ``.. versionadded::`` directive for new features
632 or configuration settings so that users know the minimum release for using
635 #. **Version Changed:** Use the ``.. versionchanged::`` directive for changes
636 in usage or configuration settings.
638 #. **Deprecated:** Use the ``.. deprecated::`` directive when CLI usage,
639 a feature or a configuration setting is no longer preferred or will be
642 #. **Topic:** Use the ``.. topic::`` directive to encapsulate text that is
643 outside the main flow of the document. See the `topic directive`_ for
650 All documents must be linked from another document or a table of contents,
651 otherwise you will receive a warning when building the documentation.
653 The Ceph project uses the ``.. toctree::`` directive. See `The TOC tree`_
654 for details. When rendering a TOC, consider specifying the ``:maxdepth:``
655 parameter so the rendered TOC is reasonably terse.
657 Document authors should prefer to use the ``:ref:`` syntax where a link target
658 contains a specific unique identifier (e.g., ``.. _unique-target-id:``), and a
659 reference to the target specifically references the target (e.g.,
660 ``:ref:`unique-target-id```) so that if source files are moved or the
661 information architecture changes, the links will still work. See
662 `Cross referencing arbitrary locations`_ for details.
664 Ceph documentation also uses the backtick (accent grave) character followed by
665 the link text, another backtick and an underscore. Sphinx allows you to
666 incorporate the link destination inline; however, we prefer to use the use the
667 ``.. _Link Text: ../path`` convention at the bottom of the document, because it
668 improves the readability of the document in a command line interface.
671 .. _Python Sphinx: http://sphinx-doc.org
672 .. _resturcturedText: http://docutils.sourceforge.net/rst.html
673 .. _Fork and Pull: https://help.github.com/articles/using-pull-requests
674 .. _github: http://github.com
675 .. _ditaa: http://ditaa.sourceforge.net/
676 .. _Document Title: http://docutils.sourceforge.net/docs/user/rst/quickstart.html#document-title-subtitle
677 .. _Sections: http://docutils.sourceforge.net/docs/user/rst/quickstart.html#sections
678 .. _Cross referencing arbitrary locations: http://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-ref
679 .. _The TOC tree: http://sphinx-doc.org/markup/toctree.html
680 .. _Showing code examples: http://sphinx-doc.org/markup/code.html
681 .. _paragraph level markup: http://sphinx-doc.org/markup/para.html
682 .. _topic directive: http://docutils.sourceforge.net/docs/ref/rst/directives.html#topic