Bug #1720

The package resource type doesn't notice installed packages when more than one is installed

Added by Trevor Hemsley over 3 years ago. Updated 3 months ago.

Status:Accepted Start date:10/30/2008
Priority:Normal Due date:
Assignee:- % Done:

0%

Category:package
Target version:2.7.x
Affected Puppet version:0.24.6 Branch:
Keywords:
Votes: 4

Description

On Redhat systems using yum as the package provider, we have a class that says

class hpasm {
# This class is meant to keep dependancies for the correct build of the various hp/compaq components
        package {"kernel-smp-devel":
                ensure => "2.6.9-67.0.1.EL",
        }
}

and rpm -q kernel-smp-devel reports

kernel-smp-devel-2.6.9-55.0.9.EL kernel-smp-devel-2.6.9-55.0.2.EL kernel-smp-devel-2.6.9-67.0.1.EL kernel-smp-devel-2.6.9-67.0.7.EL kernel-smp-devel-2.6.9-67.0.20.EL kernel-smp-devel-2.6.9-78.0.1.EL

as installed. However puppetd —test —noop says

notice: //Node[basicnode]/hpasm/Package[kernel-smp-devel]/ensure: is 2.6.9-55.0.9.EL, should be 2.6.9-67.0.1.EL (noop)

I think this is probably a bug since puppet seems to stop looking after the first rpm it finds

History

Updated by Luke Kanies over 3 years ago

  • Status changed from Unreviewed to Needs More Information

So you’re saying you’ve got multiple packages with the same name, and Puppet’s not realizing one of them is the one you’re asking for?

Updated by Trevor Hemsley over 3 years ago

Yes. Redhat (and Centos) default behaviour is to install kernel packages alongside each other and not upgrade them. This means you can have several packages of the same name installed of different releases. It’s controlled by a setting in /etc/yum.conf like so:

installonlypkgs=kernel, kernel-smp, kernel-bigmem, kernel-enterprise, kernel-devel, kernel-smp-devel, kernel-bigmem-devel, kernel-enterprise-devel, kernel-debug, kernel-unsupported, kmod-drbd-smp, kmod-drbd

Updated by Luke Kanies over 3 years ago

  • Subject changed from ensure gets confused with kernel packages to The package resource type doesn't notice installed packages when more than one is installed
  • Category set to package
  • Status changed from Needs More Information to Accepted
  • Assignee set to Puppet Community
  • Target version set to 4

So this is more of a “more than one package is installed” problem, than being something specific to kernel packages.

Updated by James Turnbull almost 3 years ago

  • Assignee deleted (Puppet Community)

Updated by Robert Lazzurs over 2 years ago

  • Status changed from Accepted to Duplicate

Hello,

On line 17 of the manifest is the package line in the first report. I agree that this bug is a duplicate of the other bug linked to it. The basic issue being the puppet yum handler not handling duplicates of the same package very well.

Updated by James Turnbull almost 2 years ago

  • Status changed from Duplicate to Accepted
  • Target version changed from 4 to 2.7.x

Updated by James Turnbull almost 2 years ago

  • Status changed from Accepted to Duplicate

Updated by James Turnbull almost 2 years ago

  • Status changed from Duplicate to Accepted

Updated by R P Herrold over 1 year ago

Also there is a process problem here … the content in any remote archive not under the management of the using entity is volatile, and may disappear at any time

The process part of this ‘issue’ is readily solveable by a person running their mirror locally of the desired content —

Upstreams retire content. If a given management approach is counting on being able to access a specific version, run a mirror under your own control

Updated by Steve Hoffman over 1 year ago

The local mirror only helps with initial installs.

The defect is not trivial as indicated by your quote of the word issue. Without this ability, the only way to upgrade a machine’s kernel is to re-kick the box— which is heavy handed. This is a gap in the implementation of the rpm provider of the package type.

I agree that local mirrors are good for expiring content as well as acceptance gatekeeper for upstream packages.

Hope to see a solution soon!

Also available in: Atom PDF