Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 487772

Summary:	Para-Virtualized Guest Kickstart Profiles occluded from SDC non-virt kickstart page
Product:	Red Hat Satellite 5	Reporter:	Steve Salevan <ssalevan>
Component:	Provisioning	Assignee:	Mike McCune <mmccune>
Status:	CLOSED DUPLICATE	QA Contact:	Steve Salevan <ssalevan>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	530	CC:	bperkins, mmraka
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-03-27 17:16:11 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, 486216

Description Steve Salevan 2009-02-27 20:34:34 UTC

Description of problem:
As per:

https://bugzilla.redhat.com/show_bug.cgi?id=484312

we no longer maintain that there are differences between "None"-type kickstarts and "Para-Virtualized Guest"-type kickstart profiles.  Thus, the "None" option has been removed from the list of available profiles.

However, when a user tries to kickstart a physical system via the SDC, the "Para-Virtualized Guest"-type profiles do not appear, causing confusion and the gnashing of the teeth.

Version-Release number of selected component (if applicable):
530-re20090220.1

How reproducible:
Always

Steps to Reproduce:
1. Create a kickstart profile with type "Para-Virtualized Guest"
2. Go to the SDC of a registered system.
3. Provisioning->Kickstart->Schedule
4. Peruse list
  
Actual results:
The profile you created does not appear in the list

Expected results:
The profile you created appears in the list

Additional info:

Comment 1 Mike McCune 2009-03-18 22:57:41 UTC

working on this now.

Comment 2 Mike McCune 2009-03-19 00:47:17 UTC

actually after re-reading this I realized a mistake I had been propagating on IRC that there is no difference between Xen Para-Virtualized Guest type profiles and regular profiles:

The Xen based profiles use kernel-xen and thus should *not* be used for regular kickstarts.  This filtering is actually still correct and I greatly apologize for the confusion.  So in summary:

* When you are kickstarting a regular machine you should see every profile type *except* Xen Para-Virtualized.

* When you are kickstarting a virtual machine with the Virtualization GUI you should see all the profiles *except* Para Virtualized Host.

The one thing I did notice while working on this was the lameish limitation that if your system doesn't have a base channel (which sometimes happens in spacewalk) you can't view *any* kickstart profiles.  I removed this restriction and we just guess based on the server arch itself instead of the base channel.

Comment 3 Mike McCune 2009-03-19 02:31:00 UTC

scratch the above about removing the restriction on requiring a base channel.  we definitely require one as it does package installs from the base and tools channels when we schedule a kickstart.  I actually can't really remove that restriction.

Going to close as NOTABUG.  Feel free to repoen with questions if that isn't what you were expecting.

Comment 4 Brandon Perkins 2009-03-25 17:12:01 UTC

Reopening, as apparently it is a blocker...

This bug blocks feature testing because one cannot test kickstarting physical systems with PV Guest profiles, as is the intended behavior.

Mike and Steve, can you please come to some sort of agreement?

Comment 5 Steve Salevan 2009-03-27 17:16:11 UTC

We have indeed come to an agreement and we agree that this bug is, in the end, a duplicate of BZ# 487418.  The explanation: due to the general confusion surrounding the removal of the "None" type, we believed incorrectly that "Para-Virtualized Guest" kickstarts were equivalent to "None" type kickstarts.  BZ# 487418 is about clarifying this confusion in the WebUI, so I'm moving this bug to CLOSED, DUPLICATE.

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