Project

General

Profile

Actions

Bug #6006

closed

OS facts should not overwrite the OS selected to provision with

Added by Dominic Cleal over 10 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Normal
Category:
Importers
Target version:
Difficulty:
Triaged:
Fixed in Releases:
Found in Releases:

Description

Migrated from https://github.com/theforeman/foreman/issues/1489

We setup a specific Operatingsystem, 'Ubuntu 12.04 + 3.2.0-59 kernel', and selected this OS in the hostgroup for machines that need this specific kernel.

We then built the hosts successfully.

Post-build, the Operatingsystem was set to 'Ubuntu 12.04.4 LTS'. This then caused a re-build of the system to fail, as the wrong kernel was installed.

I suspect the error is around line 47 in app/services/facts_parser.rb, as for our host, the os.description field is blank, because it is filled from the hostgroup. I am unclear on what a good fix for this is, but I will try and dig into more and produce a pull request, unless someone has an easy idea on it.

Another thought of mine is that facts collection should not overwrite fields that are critical to the provisioning process.


Related issues 4 (1 open3 closed)

Related to Foreman - Bug #11937: Yum updating a managed host can invalidate its data in Foreman.New09/23/2015Actions
Related to Foreman - Bug #12076: Unable to create Mulitple OS with same name, major, minorRejected10/06/2015Actions
Related to Foreman - Feature #15078: Disable updates to operating system from Puppet factsDuplicate05/18/2016Actions
Has duplicate Foreman - Feature #12235: OS minor versions should all use the same templates, installation media, and partition tablesDuplicate10/21/2015Actions
Actions #1

Updated by Dominic Cleal over 10 years ago

I think it's likely creating a new OS if the exact major/minor numbers aren't found on the existing OS, this might contain the ".4" too.

Actions #2

Updated by Aaron Stone about 10 years ago

There are at least three problems here, all of which are caused by Foreman reassigning the Operating System out from under us.

Problem 1: I assigned the host an OS, but Foreman invented a new OS entry instead of leaving it alone.

Problem 2: I assigned the host an OS, but Foreman reassigned the host to a different OS with the same name and version, because two entries with matching name and version numbers could be returning in different order from the database at different queries. Instead of leaving it alone.

Problem 3: I assigned the host an OS, and months later did a package upgrade which changed the OS micro version, causing Foreman to reassign the OS instead of leaving it alone.

We have operating System entries like "Ubuntu 12.04 + 3.2.0 kernel" and "Ubuntu 12.04 + 3.13.0 kernel". Based on which OS I assigned to a machine, I have different netboot, templates, and parameters. These are set up as:

Name: Ubuntu
Major: 12
Minor: 04
Description: + 3.2.0 kernel
/ Description: + 3.13.0 kernel
/ Description: with alternate netboot, etc.

Can we disable Foreman from reassigning the OS based on the received facts?

Should we be using some other mechanism to control the host OS installation parameters!?

Actions #4

Updated by Dominic Cleal almost 9 years ago

  • Related to Bug #11937: Yum updating a managed host can invalidate its data in Foreman. added
Actions #5

Updated by Dominic Cleal almost 9 years ago

  • Has duplicate Feature #12235: OS minor versions should all use the same templates, installation media, and partition tables added
Actions #6

Updated by Dominic Cleal almost 9 years ago

  • Related to Bug #12076: Unable to create Mulitple OS with same name, major, minor added
Actions #7

Updated by Trey Dockendorf over 8 years ago

  • Related to Feature #15078: Disable updates to operating system from Puppet facts added
Actions #8

Updated by The Foreman Bot almost 8 years ago

  • Status changed from New to Ready For Testing
  • Pull request https://github.com/theforeman/foreman/pull/4077 added
Actions #9

Updated by Tomer Brisker almost 8 years ago

  • Bugzilla link set to 1261667
Actions #10

Updated by Anonymous almost 8 years ago

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

Updated by Dominic Cleal almost 8 years ago

  • Assignee set to Trey Dockendorf
  • Translation missing: en.field_release set to 209
Actions

Also available in: Atom PDF