Bug 501388 - Inherited attributes from distro and profile should be visible
Inherited attributes from distro and profile should be visible
Status: CLOSED CURRENTRELEASE
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Virtualization (Show other bugs)
530
All Linux
high Severity medium
: ---
: ---
Assigned To: Partha Aji
Brad Buckingham
:
Depends On:
Blocks: 457075
  Show dependency treegraph
 
Reported: 2009-05-18 17:04 EDT by Justin Sherrill
Modified: 2009-09-10 15:25 EDT (History)
3 users (show)

See Also:
Fixed In Version: sat530
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-10 15:25:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Justin Sherrill 2009-05-18 17:04:53 EDT
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 11:42:58 EDT
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 12:07:23 EDT
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 13:37:26 EDT
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 14:14:07 EDT
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 14:20:44 EDT
The cloned bug https://bugzilla.redhat.com/show_bug.cgi?id=508983
Comment 8 Brad Buckingham 2009-06-30 14:48:29 EDT
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 14:36:39 EDT
tested on dhcp77-153
Comment 10 Brandon Perkins 2009-09-10 15:25:56 EDT
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

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