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? - 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
