Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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 1RHEL Program Management
2015-04-28 10:53:20 UTC
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.
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)
@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.