On 08/01/2017 10:05 AM, Stephen John Smoogen wrote: > On 1 August 2017 at 12:32, Jeffrey Ollie <jeff@xxxxxxxxxx> 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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
