Re: Moving away from Yum/DNF repo priorities for Ceph and ceph-deploy

[Mark Nelson <mnelson@redhat.com>]

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