On 1 August 2017 at 12:32, Jeffrey Ollie <[email protected]> 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 ? -- Stephen J Smoogen.
_______________________________________________ epel-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
