From mailing list

On 1 August 2017 at 12:32, Jeffrey Ollie jeff@ocjtech.us wrote:
Building 12.1.1 for EPEL7 would be VERY bad IMNSHO. 0.80.7 is seriously out of date, but:

1) You can't upgrade directly from 0.80.7 to 12.1.1 without upgrading to at least 0.94.X and then 10.2.X first, and there are probably other intermediate steps as well (you'd have to dig through the release notes to be sure).

http://docs.ceph.com/docs/master/release-notes/#upgrading-from-pre-jewel-releases-like-hammer
http://docs.ceph.com/docs/master/release-notes/#upgrading-from-infernalis-or-hammer
http://docs.ceph.com/docs/master/release-notes/#id598
http://docs.ceph.com/docs/master/release-notes/#upgrading-from-firefly

Upgrading a Ceph installation is a non-trivial affair. Depending on the versions involved and the amount of data in your system it can take days for even a small installation. There are also a number of prerequisites that need to be checked before upgrading like the underlying filesystem used, file ownership, config settings etc.

2) I suspect that most people that are running Ceph on a CentOS/RHEL system have switched to using the repos provided by Ceph at download.ceph.com. The primary advantage of the upstream Ceph repos is that you can pin your system to a specific release train. I personally am using Jewel currently, but Ceph maintains repos for many different release trains.

I'm sure that I wouldn't be the only person that would be incredibly annoyed if a "yum upgrade" upgraded Ceph to Luminous before I was ready. For one thing, 12.1.1 is considered a release candidate by Ceph. I'm not upgrading my Ceph cluster until at least 12.2.0 (which is going to be the stable release) and likely will wait until 12.2.1. I'm also going to wait until I'm good and ready. Since major operations can take days (literally), I'm not going to do the upgrade just before I leave town for the weekend for example.

Using the upstream Ceph repos means that I can switch from Jewel to Luminous when I'm ready and still get upgrades for the kernel etc. without a lot of bother.

3) Personally I think that the Ceph packages should just be deprecated from the EPEL repo. Without the ability to provide packages for multiple release trains theres no sane way to allow the end user to stay on a specific release train until they are ready to upgrade, rather than when the package manager decides to upgrade.

I will bring this up at the meeting tomorrow, but I believe that the plan would be something like the following:

1. "Update" the current package with README.deprecated explaining why the package is being removed from the repository and what a user needs to do to get newer versions. A /usr/share/docs/ceph/upstream-ceph.repo may also be useful. [Putting in a Summary that the package is deprecated may also be useful.]

2. Announce on epel-devel and epel-announce this is going to happen.

3. push the update out to users.
4. orphan the package in EPEL
5. remove it after a month after the update went to stable.

We also need to look at coming up with tools and a process to better look at packages we have in the repository so we don't make both the maintainer (aka Kaleb) and the users lifes miserable.

Does the above sound reasonable ?