Bug #11937

Yum updating a managed host can invalidate its data in Foreman.

Added by Jason Smith about 6 years ago. Updated over 5 years ago.

Target version:
Bugzilla link:
Pull request:
Fixed in Releases:
Found in Releases:


This one is a bit tricky but I will do my best to explain it. I have a host built by foreman, so it has full management enabled on it. Built as RHEL 7.0, then I yum update it to RHEL 7.1. I also have the foreman_node.rb running on the puppetmaster pushing facts to foreman. So, the next time puppet runs on the recently yum updated host, it will update the host record to the new OS that is is running, from 7.0 to 7.1. This will immediately invalidate the host data in Foreman. Now, if I go to that host record and try to change a puppet class or parameter, I get an error like this: "Partition Table Kickstart default does not belong to RedHat 7.1 operating system". In order to fix this, I have to go to the newly created OS in Foreman, and associate the same partition table that I had for 7.0. I know it is a simple change that I only have to do once, but it seems wrong that a simple yum update on a host will immediately invalidate its host data, making any change to puppet classes or parameters impossible, until this newly created OS is fixed. When Foreman automatically creates the new 7.1 OS, can't it simply copy or inherit the same config as 7.0? As far as lifecycle management goes, I already built the OS and have now transitioned to the long term management of its config, so I shouldn't have to worry about its provisioning part anymore just because I yum updated it.

Related issues

Related to Foreman - Bug #6006: OS facts should not overwrite the OS selected to provision withClosed2014-06-02


#1 Updated by Dominic Cleal about 6 years ago

  • Category set to Importers

#2 Updated by Dominic Cleal almost 6 years ago

  • Related to Bug #6006: OS facts should not overwrite the OS selected to provision with added

Also available in: Atom PDF