puppetlabs / puppetlabs/pe_patch

pe_patch fact generation listing duplicates causing fatal puppet errors

Open
#108 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Ruby
Stars
4
Forks
1
Avg merge
44m
Merged PRs (30d)
1

Description

Affected Puppet, Ruby, OS and module versions/distributions

Puppet: 7.34.0 and 8.13.1
Running in PE v2023.8.4
OS: RHEL 8

How to reproduce (e.g Puppet code you use)

Have a package update available in two different simultaneously enabled repos available to yum/dnf. Allow pe_patch_fact_generation.sh to run on the node. Attempt to run puppet with the patching modules that use the fact generated by the above script.

What are you seeing

The generated puppet fact pe_patch::package_updates will list the available updates twice as they appear in two repos as the above script does not attempt any deduplication of data. This causes a duplicate resource declaration in puppet as it appears the PE modules which consumes pe_patch::package_updates, which then causes a fatal error preventing any puppet configuration from being applied. Included that needed to clean up the duplicate repos...

What behaviour did you expect instead

Obviously, having repos with duplicate packages in is not ideal, so this can be fixed by rationalising the repo config on the affected hosts. However, I would hope that this could be accounted for by deduplicating the list of available updates, or at worst handling this 'error' condition in a non-fatal way. Yum will quite happily update a package which appears in two separate repos by syntactically sorting the repos and using the first. But in this situation this duplication of package names in the pe_patch fact completely breaks puppet until the updates are manually applied, then the patching module works - but only because there are no longer any updates. Any new updates added to both repos will then break puppet again preventing the update.

Output log

# puppet facts pe_patch
{
  "pe_patch": { ...
    "package_updates": [
      "fping.x86_64",
      "fping.x86_64",
      "haveged.x86_64",
      "haveged.x86_64",
      "libbsd.x86_64",
      "libbsd.x86_64",
       ....

On a node, this causes the patching module in puppet to fatally error with:

Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, Duplicate declaration: Package[fping.x86_64] is already declared at (file: /etc/puppetlabs/puppetserver/code/environments/.../modules/patching/manifests/patch.pp, line: 21); cannot redeclare (file: /etc/puppetlabs/puppetserver/code/environments/.../modules/patching/manifests/patch.pp, line: 21) 

Any additional information you'd like to impart

I'd quite happily accept that this isn't exactly a bug in the fact generation script so could be better described as a feature request to resolve a fatal error condition caused by non-optimal repo creation. Not trying to point fingers, but if it's known the output of a fact is being consumed directly to generate identically named puppet resources, and we know that such resources have to be unique, it may be reasonable to ensure the list cannot contain duplicates.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with pe_patch_fact_generation.sh and reproduce the fact generation on a node with the same package available from two enabled repositories. Check the generated pe_patch::package_updates output and the resulting Puppet resource declarations; done means duplicate package entries no longer cause the reported fatal duplicate declaration.

Written by the indexing model from the issue text.

Assessment

Tech stack
shell
Domain
devops
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.