User Tools

Site Tools


General Lab Info (Mainly for Devs)


Lab Infrastructure Services

Misc Admin Tasks
These are infrequently completed tasks that don't fit under any specific service

Production Services

RHEV = Sepia RHE instance
Baremetal = Host in Sepia lab

The Attic/Legacy Info


Ceph Release FAQ

The full release process is defined here:

The following FAQ is based on questions that arose when we previously followed the release process.

See Walkthrough: Ceph Release Process for a live explanation of this document.

  1. What if something went wrong with the ceph-tag job and a version commit PR was not created?
    1. You can create a version commit PR manually by performing the steps defined in the ansible role ( manually.
  2. What if ssh issues occur during the signing step?
  3. What if one of the builds during the build step fails?
    1. As noted in “Starting the Build”, if for some reason the build has to be restarted (for example if one distro failed) then you should rerun the “MultiJob Project ceph” Jenkins job with the TAG option unchecked, and only include the subset of distros/platforms we want to rebuild.
  4. What if the ceph-release RPM step was missed for a new major release?
  5. What if the “ceph-container” step is building images for an older release rather than the new one?
    1. If building for a major release, you may have forgotten to update the ceph-container github repository with the new release name. See\ container for more details on how to update this.
  6. How can I gain access to the signer machine?
  7. What if the “ceph-release-rpm” Jenkins job fails on one of the RPM repos?
    1. Something might be wrong with the script that performs this job. You may want to check the logs under the job for hints, and you may have to fix something in the script here: For instance, when centos 9 was added to the script, a syntax error was introduced, which was fixed here:
  8. Do I need to follow the “ceph-release-rpm” step for an RC?
    1. Yes. The “ceph-release” rpm is needed for every new major release. If we define a new major release as “X.Y.Z”, the “ceph-release-rpm” step should be followed for every new “X” release (regardless of Y or Z). In other words, if the first major release is 18.1.0, we should complete the “ceph-release-rpm” step. If we had instead started by releasing 18.2.0, the same would be true. However, if we release 18.1.0 and do the “ceph-release-rpm” step, we would not need to follow this step again for 18.2.0.
    2. The only reason you’d want to do this step more than once for a release is to update /etc/yum.repos.d/ceph.repo. But occurrences of this are rare.
  9. What happens if a last minute PR needs to be added to a release after the build process has begun?
    1. As long as all build artifacts are in the staging area and are not officially released, we can follow this procedure:
      1. Redo the build step of the release process ( as normal, with `TAG` checked.
  10. If we need to add a new distro, we need to update it like in this PR:
tasks/ceph-release-faq.txt · Last modified: 2023/11/21 18:14 by ljflores