Bug 1183097 - Sync-up ceph in epel 7
Summary: Sync-up ceph in epel 7
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: ceph
Version: epel7
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Boris Ranto
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-01-16 16:44 UTC by Boris Ranto
Modified: 2015-02-25 11:26 UTC (History)
9 users (show)

Fixed In Version: ceph-0.80.7-0.4.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-14 02:41:41 UTC


Attachments (Terms of Use)

Description Boris Ranto 2015-01-16 16:44:12 UTC
Description of problem:
Ceph client bits are on its way to RHEL 7.1 -- we need to deprecate the ceph build in epel.

Version-Release number of selected component (if applicable):
ceph-0.80.5-9.el7

How reproducible:
Always

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
It is not sufficient to just retire the package. We need to provide a virtual package that will oboslete all the previously installed ceph packages in order to allow a clean update.

Comment 1 Fedora Update System 2015-01-16 16:45:21 UTC
ceph-0.80.5-10.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/ceph-0.80.5-10.el7

Comment 2 Fedora Update System 2015-01-17 19:16:43 UTC
Package ceph-0.80.5-10.el7:
* should fix your issue,
* was pushed to the Fedora EPEL 7 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing ceph-0.80.5-10.el7'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0335/ceph-0.80.5-10.el7
then log in and leave karma (feedback).

Comment 3 Anssi Johansson 2015-01-19 19:28:56 UTC
After thinking about this for a while, I think the Obsoletes logic should be in RHEL 7.1's version of ceph-common to make things work more reliably.

Here are some possible scenarios:

1) User has 7.0 installed, then he installs the current ceph from EPEL. Everything works fine until the empty ceph ends up to EPEL. If 7.1 is not available at that time, ceph will be broken until the user has the possibility to upgrade to 7.1. Some people will want to stick with 7.0 for whatever odd reason they may have, or perhaps they are using CentOS which won't have 7.1 available until some time after RHEL 7.1's release. Perhaps they have enabled EPEL-testing, whose empty ceph will break their system even before 7.1's release. Outcome in this scenario: empty ceph is harmful.

2) User has 7.0 installed, then he installs the current ceph from EPEL. 7.1 becomes available and at the same time the empty ceph makes it into EPEL stable. The empty ceph will obsolete the old ceph packages, clearing way for ceph-common from 7.1 which does not know about any Obsoletes. This was probably the original intention of the empty ceph package. Outcome in this scenario: works as intended.

3) User has 7.0 installed, then he installs the current ceph from EPEL. 7.1 becomes available and at the same time the empty ceph makes it into EPEL stable. The empty ceph will obsolete the old ceph packages, clearing way for ceph-common from 7.1 which also knows how to obsolete old ceph packages. Outcome in this scenario: empty ceph is useless, because ceph-common would be able to do the same task.

4) User has 7.0 installed, then he installs the current ceph from EPEL. 7.1 becomes available and there is no empty ceph in EPEL, or EPEL has been disabled in the meantime. ceph-common in 7.1 knows how to obsolete the old EPEL ceph packages. Outcome in this scenario: works as intended.

5) User has 7.0 installed, then he installs the current ceph from EPEL. 7.1 becomes available and there is no empty ceph in EPEL, or EPEL has been disabled in the meantime. ceph-common in 7.1 does not know to obsolete the old EPEL ceph packages. Outcome in this scenario: conflicts, depending on which ceph packages RHEL 7.1 actually ships with.

6) User has 7.1 installed, wants to install ceph. As the version in 7.1 is newer than what is in EPEL, the 7.1 version will be used. Outcome in this scenario: empty ceph is useless.

Having the Obsoletes logic in 7.1's ceph-common would make the problems in 1 and 5 go away. I don't see a scenario in which that approach would be harmful. If the Obsoletes logic is in ceph-common, it would make the empty ceph in EPEL unneeded. In this case the current ceph in EPEL could be simply retired after some time after 7.1's release. Having the old version of ceph in EPEL for a while would not be particularly harmful.

Comment 4 Boris Ranto 2015-01-20 11:25:39 UTC
The thing is that base RHEL has got pretty much nothing to do with EPEL, I believe you should only deal with what is in base RHEL as you don't know what the other repositories that customers use might look like. That is why I don't want to put the obsoletes to the base rhel package. The other thing is that not all the packages will be present in base RHEL and I really don't like the idea that a component obsoletes packages that has never been provided in the repo...

Yes, the update would remove the packages (well, that is the whole point of the update) and yes, I want to do it in advance so that the repos get synced before 7.1 is released. The whole point of that update was to allow a clean update which a simple fedpkg retire would not do.

I've also given this a bit more thought and what we could do is to use ceph-deploy that is now in epel 7. We could make ceph-deploy obsolete the older ceph packages as it provides ceph in a way (and then we can retire ceph in epel 7). This might be the best solution for now. This would provide a clear statement that we obsoleted epel 7 ceph packages in favor of ceph.com packages in epel 7. Any thoughts?

Comment 5 Boris Ranto 2015-01-20 14:34:00 UTC
OK, right now I'm very much inclined to the solution that I suggested (putting obsoletes to ceph-deploy) which really seems to make the most sense to me. I've already removed the virtual ceph package from testing epel 7 repo and tested the update paths with the approach that I suggested, see the following scratch build for details on ceph-deploy patch:

http://koji.fedoraproject.org/koji/taskinfo?taskID=8674490

Unless an objection is made in the next few days, I'll push the obsoletes patch to ceph-deploy package and retire ceph afterwards.

Also, given the above, I'm changing the component to ceph-deploy.

Comment 6 Anssi Johansson 2015-01-20 15:17:43 UTC
I don't think it makes that much of a difference whether the obsoletion happens by ceph or ceph-deploy, as both are EPEL packages. The users will get the clear statement that the EPEL ceph is gone when their EPEL ceph stops working, regardless of which EPEL package obsoleted the ceph bits. I guess I will just point people to this bug if someone complains.

Comment 7 Boris Ranto 2015-01-20 17:06:51 UTC
Considering how many people do actually use epel 7 ceph packages, we have further discussed this and (at least for now) we have decided to ship full ceph package in epel 7 as it is the only way that we can keep shipping ceph in epel 7. The minor version will be synced up with what will be in base rhel while the base rhel client packages will update the epel client packages -- this effectively means that epel 7 package will be frozen in version 0.80.7.

-> moving back to ceph and changing the bz name to reflect the new heading

Comment 8 Anssi Johansson 2015-01-20 17:52:48 UTC
Thanks, this sounds good. I was primarily concerned that users' systems would break (even if only temporarily), and looks like this approach would help with that problem.

Comment 9 Boris Ranto 2015-01-20 18:47:30 UTC
We have decided to keep it mainly because of the demand (*) and the fact that base rhel won't provide full replacement for ceph packages. AFAIK, epel rules state that we should not ship packages that overlap but I believe that in this case it is justifiable and the epel packages that do in fact overlap will always be updated by the packages in base rhel.

(*) I really did not expect the demand for epel ceph packages to be so high.

Comment 10 Fedora Update System 2015-01-21 08:50:19 UTC
ceph-0.80.7-0.4.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/ceph-0.80.7-0.4.el7

Comment 11 Ken Dreyer 2015-01-21 20:13:59 UTC
I just wanted to note this here so it's explicit for everyone: we will be keeping the "Release" value in EPEL below 0 for the foreseeable future. This is because we want the ceph packages in RHEL 7.1 and the future Red Hat Ceph Storage product to supersede what is in EPEL.

Comment 12 Fedora Update System 2015-01-24 18:46:16 UTC
Package ceph-0.80.7-0.4.el7:
* should fix your issue,
* was pushed to the Fedora EPEL 7 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing ceph-0.80.7-0.4.el7'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0377/ceph-0.80.7-0.4.el7
then log in and leave karma (feedback).

Comment 13 Fedora Update System 2015-02-14 02:41:41 UTC
ceph-0.80.7-0.4.el7 has been pushed to the Fedora EPEL 7 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.