Project

General

Profile

Bug #2244

avoid flapping os.release_name for Debian

Added by Florian Ernst almost 10 years ago. Updated about 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Sam Kottler
Category:
Audit Log
Target version:
Difficulty:
Triaged:
No
Bugzilla link:
Pull request:
Fixed in Releases:
Found in Releases:
Red Hat JIRA:

Description

If some hosts provide facts[:lsbdistcodename] but other hosts don't,
os.release_name constantly changes when importing the facts, thus
filling your audit logs with useless massages.

The attached patch saved me a ton of audit logs, please consider including it.

Associated revisions

Revision d74b482e (diff)
Added by Florian Ernst about 9 years ago

Fixes #2244: avoid constantly changing os.release_name

Tests thanks to Sam Kottler <>

Revision f0f429c8 (diff)
Added by Florian Ernst about 9 years ago

Fixes #2244: avoid constantly changing os.release_name

Tests thanks to Sam Kottler <>

(cherry picked from commit d74b482e34eceda22024f085579d58b4985524ce)

History

#1 Updated by Florian Ernst over 9 years ago

JFTR, this issue is still valid with 1.2.2, and my patch still fixes it.

#2 Updated by Dominic Cleal over 9 years ago

  • Description updated (diff)

Would you mind submitting this as a pull request to the project on GitHub? It's our normal way to get patches included in Foreman.

There are some instructions on the contributing page on the main website: http://theforeman.org/contribute.html

#3 Updated by Florian Ernst over 9 years ago

Thanks for the reply.

Well, for an occasional contributer that's an awful lot of hoops to jump through for single line patch:
I sent it via mail and was told to file it in an issue, so I needed to create a redmine account. And now,
after the issue remained untouched for months, I apparently need github as well to get things going.
Please bear in mind that I got in contact with the intention to help (lest my patch remains private), but
it seems I have to go to lengths to present my help (as little as it is) on a silver platter ...

Considering that, it'd probably be easier for me to just individually apply my patch after each foreman
upgrade, and that's a notion I don't like myself to think. So I'll see what I can do, but it might take a
while to get acquainted.

#4 Updated by Sam Kottler over 9 years ago

  • Status changed from New to Assigned
  • Assignee set to Sam Kottler
  • Target version set to 1.3.0

Florian,

Sorry about the confusion - our contribution process has been the same for a while (outlined in http://projects.theforeman.org/projects/foreman/wiki/Contribute#Submit-Patches). The patch is appreciated!

I'll submit this as a pull request on your behalf and when it gets merged we can give you authorship in Git.

#5 Updated by Sam Kottler over 9 years ago

  • Status changed from Assigned to Ready For Testing

#6 Updated by Lukas Zapletal about 9 years ago

  • Target version changed from 1.3.0 to 1.4.0

#7 Updated by Dominic Cleal about 9 years ago

  • Related to Tracker #3112: [TRACKER] Issues to be released in 1.3 RC or final added

#8 Updated by Dominic Cleal about 9 years ago

  • Target version changed from 1.4.0 to 1.3.0

#9 Updated by Anonymous about 9 years ago

  • Status changed from Ready For Testing to Closed
  • % Done changed from 0 to 100

#10 Updated by Lukas Zapletal about 9 years ago

  • Related to deleted (Tracker #3112: [TRACKER] Issues to be released in 1.3 RC or final)

Also available in: Atom PDF