Bug 501388

Summary: Inherited attributes from distro and profile should be visible
Product: Red Hat Satellite 5 Reporter: Justin Sherrill <jsherril>
Component: VirtualizationAssignee: Partha Aji <paji>
Status: CLOSED CURRENTRELEASE QA Contact: Brad Buckingham <bbuckingham>
Severity: medium Docs Contact:
Priority: high    
Version: 530CC: bbuckingham, bperkins, jbrownin
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: sat530 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-10 19:25:56 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 457075    

Description Justin Sherrill 2009-05-18 21:04:53 UTC
When setting things like kernel opts & post-kernel opts at the profile level, we should show what the value is already set to (as it was inherited from the upper level). 

At the provisioning level (on bare metal and virt provisioning) we should show what the inherited values are from the profile (or distro).

This was based off a review with Taw, Chris Wells, and Mpdehann.

Comment 1 Brandon Perkins 2009-05-19 15:42:58 UTC
Justin, please provide more explicit steps (perhaps with example data).  Cliff and I couldn't follow exactly what we're talking about here.  And we would need this information for a test plan anyway.

Comment 2 Justin Sherrill 2009-05-19 16:07:23 UTC
So with our cobbler integration there is the idea of inheritance among distro, profile, system

The inheritance works as follows.  If certain values are not defined for a system, the profile is looked to for those values.  If it is not defined there then the distro is looked to. 

For example, say you had a Distro who's hardware detection was broken, you could add 'noprobe' as a kernel option in the distro level, and all deployments of that distro would use that kernel option.  But if you set the kernel option for a particular kickstart, it will ignore what's set in the profile.  


1.  So on the profile details edit page, where you set the kernel and post kernel options, we need to provide a way for you to see what the distro is set to, so you know i you need to override it or not.

2.  On the system provisioning page we should show you what is inherited (if it's from distro or profile), so you know if you need to override it or not. 

Otherwise you have to navigate back to the profile and possible to the distro to know what' it's actually going to use for that value (if you don't set it).

Comment 5 Brad Buckingham 2009-06-30 17:37:26 UTC
Satellite-5.3.0-RHEL5-re20090625.0-i386-embedded-oracle.iso

1) Systems->Kickstart->Profiles->profile - selected a profile that has defined both Kernel and Post Kernel options.  From the profile details page (rhn/kickstart/KickstartDetailsEdit.do), do not see any indication of what the distros options are.  Per item 1 in the initial description, it seems that those details should be provided. *Fail*

2) Systems->system->Provisioning->Advanced Configuration - accessing the Advanced Configuration (prior to scheduling a kickstart) when the Profile and Distro have both Kernel and Post Kernel options, I am able to see from that page (rhn/systems/details/kickstart/ScheduleWizard.do) the options that are set in the Profile and Distro.  *Pass*

Comment 6 Partha Aji 2009-06-30 18:14:07 UTC
I think while it would be nice to see what the distro has when the profile is being edited, the advanced options in the page in KS schedule makes it amply clear what the user will actually see. I am going to open a separate bug for part 1 and punt it to next release.

Comment 7 Partha Aji 2009-06-30 18:20:44 UTC
The cloned bug https://bugzilla.redhat.com/show_bug.cgi?id=508983

Comment 8 Brad Buckingham 2009-06-30 18:48:29 UTC
Moving to verified since the item marked as failed in Comment #5 has been broken out in to a separate bug (see Comment #7).

Comment 9 Jeff Browning 2009-07-29 18:36:39 UTC
tested on dhcp77-153

Comment 10 Brandon Perkins 2009-09-10 19:25:56 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-1434.html