On 07/23/2015 06:12 PM, Travis Rhoden wrote:
HI Everyone, I’m working on ways to improve Ceph installation with ceph-deploy, and a common hurdle we have hit involves dependency issues between ceph.com hosted RPM repos, and packages within EPEL. For a while we were able to managed this with the priorities plugin, but then EPEL shipped packages that included changes that weren’t available on the ceph.com packages, and the EPEL packages “obsoleted” the ceph.com ones. This caused EPEL packages to take priority over ceph.com packages even when ceph.com packages had greater version numbers. The solution to this was to enable the “check_obsoletes” feature of the priorities plugin. That’s where we are today. Recently when working with DNF, I observed that the priorities feature got pulled natively into DNF, but I cannot find anything about whether “check_obsoletes” is still necessary or even an option. Regardless, I would like move away from this workflow as it is generally seen as poor. [1] [2] What I’d like to propose instead of ceph-deploy’s current workflow is to: (1) install epel-release on nodes that need it (2) disable EPEL by default (using yum-config-manager) (3) When installing Ceph, break the install into two parts (3)(a) Explicitly install Ceph’s dependencies from EPEL by name, using yum —enablerepo=epel (3)(b) Proceed normally with Ceph installation, but adding a —disablerepo=epel flag as well Note: the disabling of EPEL in 3b seems redundant with 2, but it would cover cases when a user/admin chooses to enable EPEL by default. We are mostly concerned with nodes that are dedicated to Ceph and therefore ceph-deploy is free to do things like disabling EPEL, but that’s certainly not always ideal. We could disable it by default *only* if we were the ones to install it. If it’s already there, we leave it along but then still do our two-phase install and explicitly disable it when doing the second phase of install. I think this workflow would allow us to no longer need to use repo priorities, but I might be missing something. A secondary motive to this is to end up with systems that EPEL disabled by default because it has caused issues with Calamari, where EPEL has newer packages of certain things than what gets installed initially and then breaks Calamari. Having EPEL disabled will prevent that, and will also prevent things like “yum update” from breaking things. Potential downsides I see are what happens when there are updates in EPEL that we want, say for a security fix?
Packaging issues have definitely been a pain. I must admit I don't know all of the ins and outs, so take my opinion with a grain of salt. The above, at least to me, seems like it's kind of trying to skirt around the problem by making ceph-deploy jump through hoops to get ceph installed (disabling epel yet installing packages from epel?). These are the kinds of hacks we did at the Supercomputing institute all the time and they have a habit of building on themselves and leaking out in strange ways. :)
If there's really no better way around this, I think we need to communicate to the Yum/DMF team(s) what the problem is and that we need to come up with some better way to control the priorities. Given that DMF is fairly new, it seems like a prime time to work with them no?
- Travis [1] http://wiki.centos.org/PackageManagement/Yum/Priorities#head-38b91468cc607d0243f463489c2334bf40bfaaee [2] http://wiki.centos.org/PackageManagement/Yum/Priorities#head-6601a4937d4b099e6d46eea0bdb54241d51c7277-- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
-- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
