Bug 884399

Summary: cannot remove default install options when provisioning a manual system
Product: [Retired] Beaker Reporter: Dan Callaghan <dcallagh>
Component: web UIAssignee: Dan Callaghan <dcallagh>
Status: CLOSED CURRENTRELEASE QA Contact: tools-bugs <tools-bugs>
Severity: unspecified Docs Contact:
Priority: low    
Version: 0.10CC: aigao, asaha, dcallagh, jzhao, pbunyan, qwan, rmancy, tools-bugs
Target Milestone: 19.0Keywords: Regression
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: UX
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-11-25 07:18:39 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:
Bug Depends On: 1014438    
Bug Blocks:    

Description Dan Callaghan 2012-12-06 06:44:31 UTC
When manually provisioning a system, the Provision tab has some js to populate the ksmeta and kernel options fields when a distro tree is selected. (The install options are generated from the global defaults + distro tree options + system options.) The user then has an opportunity to edit these before provisioning. If they remove an argument that has been populated by the js, it will be put back when Beaker does the provision.

Steps to reproduce:
1. Go to system page for a Manual system
2. Take the system, so that you are its current user
3. Go to Provision tab
4. Click a distro tree and wait for js to populate install options. At least ksdevice=bootif should appear in kernel options since it is shipped as a global default option in Beaker.
5. Delete ksdevice=bootif from Kernel Options and hit Provision.

Actual results:
ksdevice=bootif still appears in kernel command-line arguments (check provision.log on LC).

Expected results:
Install options as edited by the user are obeyed.

This is because the InstallOptions overriding code is being applied for manual provisioning where it probably shouldn't. It's essentially a regression in Beaker 0.9 when the new InstallOptions code was added.

Workaround: instead of deleting the option, prepend it with ! to make Beaker delete it in the InstallOptions overriding code.

Comment 2 Dan Callaghan 2014-01-21 01:49:05 UTC
This will be fixed with the system page improvements in bug 1014438. The new provision tab no longer populates install option fields using JavaScript. The install options are instead treated as *extra* options on top of the inherited defaults, which brings it in line with other parts of Beaker (recipe install options and reserve workflow) and avoids this bug as well as some serious timing issues with the asynchronous population.

Comment 7 Dan Callaghan 2014-10-07 01:57:52 UTC
*** Bug 1149228 has been marked as a duplicate of this bug. ***

Comment 8 Dan Callaghan 2014-11-25 07:18:39 UTC
Beaker 19.0 has been released.