Hide Forgot
Description of problem: If you use bkr system-provision it will ignore the kernel_options and kernel_options_post which are defined for that host. The call is the same as the WebUI but the difference is the webui has javascript to pull in the default values before calling action_provision. Version-Release number of selected component (if applicable): 0.6.9 How reproducible: Every time I suggest we make a call to get_installoptions in controllers.py, we might want to move this into another bit of code to keep the logic separate from the controllers. Open to suggestions.
Should we have the ks_meta, kernel_options, and kernel_options_post arguments override the system defaults? That way if the caller doesn't specify any kernel options we will use the defaults for that distro on the system. We already have some logic to handle this: the System.install_options method (model.py:1827) takes ks_meta, kernel_options, and kernel_options_post arguments. The XML-RPC method could just call that and pass in the appropriate values.
Yes they should go through system.install_options(). That code handles inheritance of options and allows options to be removed by adding !console for example to undefine console=ttyS0. But to be clear, we are not overriding the defaults, we are modifying them. If you specify kernel_options="my_cmd_line_arg=foo" and the system kernel_options have console=ttyS0,115200 ksdev=eth0 You will end up with console=ttyS0,115200 ksdev=eth0 my_cmd_line_arg=foo Make sense?
Hello, Your ticket is ready for testing and is currently running on https://beaker-stage.app.eng.bos.redhat.com Please ensure your request for beaker has been adequately addressed by testing it on the above machine. Testing will be available up until COB on the 20th April. Thank you Beaker development team