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