Bug 884399 - cannot remove default install options when provisioning a manual system
cannot remove default install options when provisioning a manual system
Status: CLOSED CURRENTRELEASE
Product: Beaker
Classification: Community
Component: web UI (Show other bugs)
0.10
Unspecified Unspecified
low Severity unspecified (vote)
: 19.0
: ---
Assigned To: Dan Callaghan
tools-bugs
UX
: Regression
: 1149228 (view as bug list)
Depends On: 1014438
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-06 01:44 EST by Dan Callaghan
Modified: 2014-11-25 02:18 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-11-25 02:18:39 EST
Type: Bug
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 Dan Callaghan 2012-12-06 01:44:31 EST
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-20 20:49:05 EST
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-06 21:57:52 EDT
*** Bug 1149228 has been marked as a duplicate of this bug. ***
Comment 8 Dan Callaghan 2014-11-25 02:18:39 EST
Beaker 19.0 has been released.

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