On 1 August 2017 at 12:32, Jeffrey Ollie <jeff(a)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.
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 ?
Yep. Agreed on all points.
kevin