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

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

[Travis Rhoden]

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

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

[Travis Rhoden]

<sorry for double-send — forgot to make plain text for ceph-devel>

Hi Shinobu,

Thanks for the response.


> On Jul 23, 2015, at 5:05 PM, Shinobu Kinjo <shinobu.kj@gmail.com> wrote:
> 
> Hi Travis,
> 
> Is this that you are talking about:
> 
> ``dnf [options] list obsoletes [<package-name-specs>...]``
> ``dnf [options] repository-packages <repoid> info obsoletes [<package-name-spec>...]``
> ``dnf [options] repository-packages <repoid> list obsoletes [<package-name-spec>...]``

Partially.  Those queries either list packages already installed that are obsoleted by packages available in any enabled repos, or list packages in the repos that obsolete packages that are already installed (the man page says reposository-packages info/list are the same thing?).  Such commands would show the issue I am trying to solve - namely that for certain releases of Ceph, older packages of Ceph from EPEL take priority over newer ones, due to package obsoletions.

The exact scenario we hit was a problem most commonly on CentOS - I have not confirmed whether it is an issue in Fedora.  But here is a specific example.  Starting with a CentOS 7 machine that has EPEL installed/enabled, and Ceph rpm-firefly enabled by default, and the yum priorities plugin installed (with check_obsoletes=0):

# yum info --disablerepo=Ceph --disablerepo=epel --disableplugin=priorities ceph
Error: No matching Packages to list
^ Expected - ceph packages aren’t reachable

# yum info --disablerepo=Ceph --disableplugin=priorities ceph
Available Packages
Name        : ceph
Arch        : x86_64
Epoch       : 1
Version     : 0.80.7
Release     : 0.4.el7
^ EPEL includes Ceph 0.80.7.

# yum info --disablerepo=epel --disableplugin=priorities ceph
Available Packages
Name        : ceph
Arch        : x86_64
Epoch       : 1
Version     : 0.80.10
^ Ceph repos have 0.80.10.

# yum info --disableplugin=priorities ceph
Available Packages
Name        : ceph
Arch        : x86_64
Epoch       : 1
Version     : 0.80.7
^ With priorities disabled, but both repos enabled, yum resolves the lower version number, 0.80.7 from EPEL.

# yum info ceph
24 packages excluded due to repository priority protections
Available Packages
Name        : ceph
Arch        : x86_64
Version     : 0.80.10
^ With priorities enabled, we now get 0.80.10.  The ceph.repo file has priority=1 in it.

Great!  With priorities enabled, we now see 0.80.10.  Let’s install:

# yum install -v ceph
….
….
Error: Package: 1:python-rbd-0.80.7-2.el7.x86_64 (base)
           Requires: librbd1 = 1:0.80.7-2.el7
           Available: librbd1-0.80-0.el7.x86_64 (Ceph)
               librbd1 = 0.80-0.el7
           Available: librbd1-0.80.1-0.el7.x86_64 (Ceph)
               librbd1 = 0.80.1-0.el7
           Available: librbd1-0.80.3-0.el7.x86_64 (Ceph)
               librbd1 = 0.80.3-0.el7
           Available: librbd1-0.80.4-0.el7.x86_64 (Ceph)
               librbd1 = 0.80.4-0.el7
           Available: librbd1-0.80.5-0.el7.x86_64 (Ceph)
               librbd1 = 0.80.5-0.el7
           Available: librbd1-0.80.6-0.el7.x86_64 (Ceph)
               librbd1 = 0.80.6-0.el7
           Available: librbd1-0.80.7-0.el7.x86_64 (Ceph)
               librbd1 = 0.80.7-0.el7
           Available: librbd1-0.80.8-0.el7.x86_64 (Ceph)
               librbd1 = 0.80.8-0.el7
           Available: librbd1-0.80.9-0.el7.x86_64 (Ceph)
               librbd1 = 0.80.9-0.el7
           Installing: librbd1-0.80.10-0.el7.x86_64 (Ceph)
               librbd1 = 0.80.10-0.el7


So why did the install fail?  See [1] for full output, but the short version is at this step:

--> Processing Dependency: python-ceph for package: ceph-0.80.10-0.el7.x86_64
Searching pkgSack for dep: python-ceph
Not Updating Package that is obsoleted: python-ceph-0.80.10-0.el7.x86_64
TSINFO: Marking 1:python-ceph-compat-0.80.7-0.4.el7.x86_64 as install for ceph-0.80.10-0.el7.x86_64

When yum looks for python-ceph, it sees that it has been marked as obsoleted by python-ceph-compat, which is available from EPEL.  Pulling in that python-ceph-compat causes all kinds of problems and the install ultimately fails.  The solution is set check_obsoletes = 1 in /etc/yum/pluginconf.d/priorities.conf, which forces Yum to override the the obsoletion of a package from a lower priority repo.  This is what we are doing today.

This problem still exists for our Firefly and Giant packages, even though the EPEL package added versions to their obsoletes over 4 months ago: [2].  It is this “check_obsoletes” behavior that I am unsure of in DNF.  Granted, I haven’t tried it.  It may be that it will read the same config file, even (/etc/yum/pluginconf.d/priorities.conf).  I’d have to install DNF in a Fedora 20 VM (the last Fedora we built production packages of Firefly on) to see how DNF behaves here.

Even if check_obsoletes wasn’t a consideration, I’d really like to get away from setting priority values in repo files and installing an additional plugin for Yum to make things work.  It feels like it is using magic numbers to make things resolve correctly.  Maybe this is entirely invalid, since having the priorities plugin rolled into DNF gives it an air of legitimacy.  I wanted to reach out to the Ceph community to see if a two phased install with a disabled-by-default EPEL made sense.  I also wanted to see if any Yum/DNF experts said I was crazy. :)

As the yum examples in here show, having EPEL enabled can lead to unexpected resolutions. It is not immediately obvious to most people why 0.80.7 from EPEL would be picked by Yum instead of 0.80.10 that’s on ceph.com.  And even when the resolution of a top-level package produces the correction version, that doesn’t mean that all the dependencies are going to resolve well.

[1] http://fpaste.org/247700/14377137/
[2] http://pkgs.fedoraproject.org/cgit/ceph.git/commit/?h=epel7&id=c9a91bad2f3c3083b8dad7a1feb9f84994c2f35c

 - Travis

> 
>  - Shinobu
> 
> 
> On Fri, Jul 24, 2015 at 8:12 AM, Travis Rhoden <trhoden@redhat.com> 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?
>> 
>>  - 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
> Life w/ Linux
> 

--
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

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

[Pete Zaitcev]

On Thu, 23 Jul 2015 16:12:59 -0700
Travis Rhoden <trhoden@redhat.com> wrote:

> 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 happens every time repos want to conflict with packages provided
by the base distro or EPEL. I think the only sensible way to manage it is
not to conflict and rely on the base packages. That means getting the right
versions in. In old EPEL/CentOS/RHEL this may mean versioned names or other
tricks, but the point is to get them in. You have access to experienced
packagers such as Haikel G., who can help you.

So, I'm just curious, what are the specific pain points that we're hitting,
which prevent using EPEL packages? What are you duplicating and why?

-- Pete
--
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

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

[Andrew Woodward]

We already had a similar problem with stackforge/puppet-ceph and went
around in circles for a while trying to account for the issue. We
ultimately resulted in [1] to resolve the issue for us.

[1] https://review.openstack.org/#/c/197302/1/manifests/repo.pp


On Fri, Jul 24, 2015 at 4:28 PM Pete Zaitcev <zaitcev@redhat.com> wrote:
>
> On Thu, 23 Jul 2015 16:12:59 -0700
> Travis Rhoden <trhoden@redhat.com> wrote:
>
> > 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 happens every time repos want to conflict with packages provided
> by the base distro or EPEL. I think the only sensible way to manage it is
> not to conflict and rely on the base packages. That means getting the right
> versions in. In old EPEL/CentOS/RHEL this may mean versioned names or other
> tricks, but the point is to get them in. You have access to experienced
> packagers such as Haikel G., who can help you.
>
> So, I'm just curious, what are the specific pain points that we're hitting,
> which prevent using EPEL packages? What are you duplicating and why?
>
> -- Pete
> --
> 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

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

[Travis Rhoden]

Hi Pete,

Thanks for the input.  I think Ken can probably help shed some light
on this as well for you, but some things I can add...

On Fri, Jul 24, 2015 at 4:24 PM, Pete Zaitcev <zaitcev@redhat.com> wrote:
> On Thu, 23 Jul 2015 16:12:59 -0700
> Travis Rhoden <trhoden@redhat.com> wrote:
>
>> 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 happens every time repos want to conflict with packages provided
> by the base distro or EPEL.

My examples were a bit contrived, in that I purposely had to use an
"old" version of Ceph.  But it's an old version that the community
still supports for many months to come.  The latest packages do not
conflict with EPEL in any way.

However, going back in time, it was never the case that Ceph wanted to
conflict.  It was more of a case where some packages that got pushed
to EPEL were pushed a bit pre-maturely, where a package was split into
multiple subcomponents and the old packages was then obsoleted.  This
was done *before* the upstream packages had the same thing done to
them.  This only happened once, but it did cause all kind of
headaches.

> I think the only sensible way to manage it is
> not to conflict and rely on the base packages. That means getting the right
> versions in.

This is indeed what Ceph does.  It relies on what is in EPEL.  It was
just that for two of our releases (Firefly and Giant), the package
obsoletions made installation without a lot of extra configuration
impossible.  In a way this is a "one off", and does not effect the
current release Hammer.

> In old EPEL/CentOS/RHEL this may mean versioned names or other
> tricks, but the point is to get them in. You have access to experienced
> packagers such as Haikel G., who can help you.
>
> So, I'm just curious, what are the specific pain points that we're hitting,
> which prevent using EPEL packages? What are you duplicating and why?

We don't want to duplicate EPEL packages - and for the most part we
don't.  The only packages that are duplicated (I think) are Ceph
packages themselves.  EPEL includes a version of Ceph, but upstream
can and does provide repos with newer versions.  However, upstream
*also* absolutely depends on EPEL.  We use everything we can from
there.  In the cases of Firefly and Giant, there was this weird
situation where EPEL packages obsoleted our own, but that was a bit of
a feature mismanagement that we had to work around.

My proposal to install Ceph into two pieces (install Ceph EPEL
dependencies explicitly, then install the rest of Ceph with EPEL
disabled) is motived by two things. First is to simplify ceph-deploy
so that it doesn't have to add Yum plugins and configure them "just
right" to make things work.  Second is to play nice with Calamari.

Calamari is a bit more fragile when it comes to package versions.  It
depends on an older version of certain things packages that have newer
versions in EPEL.  So if there is a working installation and EPEL is
enabled, a "yum update" will break it.  I'm hoping to help with that
problem by playing nice and leaving EPEL disabled by default on Ceph
nodes.


>
> -- Pete
> --
> 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

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

[Travis Rhoden]

Andrew,

On Fri, Jul 24, 2015 at 4:52 PM, Andrew Woodward <xarses@gmail.com> wrote:
> We already had a similar problem with stackforge/puppet-ceph and went
> around in circles for a while trying to account for the issue. We
> ultimately resulted in [1] to resolve the issue for us.
>
> [1] https://review.openstack.org/#/c/197302/1/manifests/repo.pp

Yes, that was part of my motivation for re-opening this topic, and
wanting to reconsider adding "excludes" to .repo entries.  I still
wanted to find a way to not have to modify a different package's files
(e.g. epel-release owns epel.repo) though.  That's why I thought about
breaking it into two phases.

>
>
> On Fri, Jul 24, 2015 at 4:28 PM Pete Zaitcev <zaitcev@redhat.com> wrote:
>>
>> On Thu, 23 Jul 2015 16:12:59 -0700
>> Travis Rhoden <trhoden@redhat.com> wrote:
>>
>> > 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 happens every time repos want to conflict with packages provided
>> by the base distro or EPEL. I think the only sensible way to manage it is
>> not to conflict and rely on the base packages. That means getting the right
>> versions in. In old EPEL/CentOS/RHEL this may mean versioned names or other
>> tricks, but the point is to get them in. You have access to experienced
>> packagers such as Haikel G., who can help you.
>>
>> So, I'm just curious, what are the specific pain points that we're hitting,
>> which prevent using EPEL packages? What are you duplicating and why?
>>
>> -- Pete
>> --
>> 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
--
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

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

[Mark Nelson]

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

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

[Mark Nelson]

Haha, yes.  I still use yum for everything. :D

Mark

On 07/24/2015 08:18 PM, Shinobu Kinjo wrote:
>
>     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?
>
>
> I agree. But remember not DMF but DNF -;
>
>   - Shinobu
>
>
>            - 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
>         <mailto: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
>     <mailto:majordomo@vger.kernel.org>
>     More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
>
> --
> Email:
> shinobu@linux.com <mailto:shinobu@linux.com>
> skinjo@redhat.com <mailto:skinjo@redhat.com>
>
>   Life w/ Linux <http://i-shinobu.hatenablog.com/>