Bug 1239197

Summary: After Provisioning Rhel-H (hypervisor) host the value from Operating System changed
Product: Red Hat Satellite Reporter: jnikolak
Component: ProvisioningAssignee: Ohad Levy <ohadlevy>
Status: CLOSED WONTFIX QA Contact: Katello QA List <katello-qa-list>
Severity: high Docs Contact: David O'Brien <daobrien>
Priority: high    
Version: 6.0.8CC: bbuckingham, bkearney, djoo, fdacunha, jnikolak, mmccune, ohadlevy, sali
Target Milestone: Unspecified   
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-02-19 16:37:17 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
sat-rehost
none
selection_103
none
selection_144
none
screenshot share by customer none

Description jnikolak 2015-07-04 07:29:27 UTC
Created attachment 1045986 [details]
sat-rehost

How reproducible:


Steps to Reproduce:
1. Host -> New Host
2. 
Fill out 
Host
Puppet Classes
Network
Operating System -> Rhel6
Parameters

3. Click Submit

The Server will be built. Once its been built, we go back and select that host
1. Host -> All Hosts -> Host(created)

2. The Operating System shows as Rhel 6.6 and not Rhel6 as previously created.
Screenshot -> Sat-rehost
and 
Screenshot Selection_123


What is actually created is:
See Screenshot_144

This is breaking the templates that are associated with that operating system.
Why is the Operating System changing and how do we make it not change?


We have tried: 
ignore_puppet_facts_for_provisioning == true
However regardless the operating system value still changes.

Comment 1 jnikolak 2015-07-04 07:30:46 UTC
Created attachment 1045987 [details]
selection_103

Comment 2 jnikolak 2015-07-04 07:31:25 UTC
Created attachment 1045988 [details]
selection_144

Comment 3 RHEL Program Management 2015-07-04 07:34:41 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.

Comment 5 Ohad Levy 2015-07-08 05:53:14 UTC
This is by design, where it updates the OS attribute based on the facter output.
Did you create the RHEL 6 OS entry by hand? It should always be a RHEL 6.6 or similar.

Comment 7 Mohammed Shakir Ali 2015-07-08 06:23:58 UTC
Created attachment 1049712 [details]
screenshot share by customer

Comment 8 Ohad Levy 2015-07-08 06:43:19 UTC
This seems like it was created manually, there is no such thing as RHEL 6 DEV.
once the host is running, it facts create the os (if does not exists) and assign the host to it.

What does RHEL 6 Dev actually mean in this context? maybe they are using the wrong object (OS) to differentiate different type of machines?

IMHO this is not a bug.

Comment 11 Ohad Levy 2015-07-13 06:30:02 UTC
I think you are mixing up the objects in the system.
an RHEL 6.6 is RHEL 6.6, multiple CV can be attached to it, and each one could represent a different content set, environment etc.


The main issue here, is that the OS attributes are imported from the host, and dynamicilly created if there no such OS already, if at all, the request might be to not auto update the host entry with its reported run time os.

I don't see much value in RHEL6-DEV, vs RHEL6.x and a DEV CV attached to it (in a dev life cycle environment).

Ohad

Comment 13 David O'Brien 2015-08-25 23:20:53 UTC
The docs team needs suitable doc text for this so we can create a rel note.

Thanks

Comment 15 Bryan Kearney 2016-02-19 16:37:17 UTC
Based on comments above, I am closing this as WONTFIX. If this causes issues, please free free to re-open with additional business impact.