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.
2. push the update out to users.
3. orphan the package in EPEL
4. 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 ?
--
Stephen J Smoogen.