Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 1216001 - Hostgroup change does not affect host's attributes (OS, mirror, p. table) if set
Hostgroup change does not affect host's attributes (OS, mirror, p. table) if set
Status: CLOSED DUPLICATE of bug 1159886
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Host Form (Show other bugs)
6.0.8
Unspecified Unspecified
medium Severity medium (vote)
: Unspecified
: Unused
Assigned To: Daniel Lobato Garcia
Katello QA List
:
Depends On:
Blocks: 1287901
  Show dependency treegraph
 
Reported: 2015-04-28 06:43 EDT by Jan Krocil
Modified: 2017-11-14 06:04 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-09-13 08:40:23 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Foreman Issue Tracker 18912 None None None 2017-03-15 09:00 EDT

  None (edit)
Description Jan Krocil 2015-04-28 06:43:26 EDT
Description of problem:
We ran into this issue when reprovisioning a machine between 2 host groups.
If the 2 hostgroups have different OSes set, we can't switch in-between them unless we manually unset the 3 attributes first.

Version-Release number of selected component (if applicable):
Satellite 6.0.8

How reproducible:
Always

Steps to Reproduce:
1. Setup 2 hostgroups with different OSes
2. Provision a host into the 1st hostgroup (wait till finished)
3. Change hostgroup of the host to the 2nd one and enable build mode

Actual results:
Looking at the host's attributes, the OS, mirror and partition table remained in their previous state; the hostgroup change had no effect on them.
PXE was not rebuilt either and is pointing at the original OS as well.

Expected results:
Data from the hostgroup should rewrite current host's setup / attributes for reprovisioning on a hostgroup change without the user having to unset them first.

Workaround:
Unset OS, mirror and p. table from the host first and then change the hostgroup.
This will load the data from the new hostgroup.

-----------------------------

Is this an expected behavior?
Comment 1 RHEL Product and Program Management 2015-04-28 06:53:20 EDT
Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.
Comment 3 Keenan Brock 2015-04-29 11:37:02 EDT
I may be incorrect to my technical assessment but this is what I see happening.
Thanks for your help

hostgroup has an os, ptable, and media entry
host does not.

1. set the hostgroup in a host record.
2. set the host to boot and restart / provision
3. machine gets provisioned
4. formen assigns an os, ptable, and media value to the host record
5. set a different hostgroup in the host record.
6. note: the old os, ptable, and media are still in the host record.
7. set the host to boot and restart / provision
8. the machine has the old OS.

possibly related (may aid in debugging problem):
1. assign an os to a host
2. foreman changes the os to a new os record (with a slightly changed name)
Comment 5 Ohad Levy 2015-05-13 06:44:46 EDT
@Keenan, this is not exactly correct, we currently distinguish between two sets of attributes in a hostgroup - provisioning related and configuration related.

provisioning related attributes (os, ptable, media, puppet server etc) are normally used only for the provisioning process, and when creating a host, they are effectively copied from the hostgroup into the host record.

other configuration based attributes (root password, puppet classes, parameters etc) will take into consideration the hostgroup properties.

there is even a 3rd dimension for how attributes are handled when nesting hostgroups, where a hostgroup value can be nil and inherit from its parent hostgroup.

regarding foreman changing attributes after provisioning could happen via facts, e.g. a host report itself with an updated os (e.g. you installed RHEL 7.0 and did yum upgrade to 7.1) this will change the host os attribute to reflect that.

we are aware of the conflict, and already addressing this via a redesign of the host object to split to multiple aspects.
Comment 6 Bryan Kearney 2016-07-08 16:20:46 EDT
Per 6.3 planning, moving out non acked bugs to the backlog
Comment 9 Tomer Brisker 2017-03-15 09:00:30 EDT
Created redmine issue http://projects.theforeman.org/issues/18912 from this bug
Comment 11 Daniel Lobato Garcia 2017-09-13 08:40:23 EDT

*** This bug has been marked as a duplicate of bug 1159886 ***

Note You need to log in before you can comment on or make changes to this bug.