Bug 832000 - Reduce number of kargs to enable a better automated installation with PXE
Reduce number of kargs to enable a better automated installation with PXE
Status: CLOSED NOTABUG
Product: oVirt
Classification: Community
Component: ovirt-node (Show other bugs)
unspecified
Unspecified Unspecified
medium Severity medium
: ---
: 3.4.1
Assigned To: Ryan Barry
bugs@ovirt.org
node
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-14 05:12 EDT by Fabian Deutsch
Modified: 2014-04-30 07:44 EDT (History)
7 users (show)

See Also:
Fixed In Version: 2.5.2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-04-30 07:44:42 EDT
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 Fabian Deutsch 2012-06-14 05:12:39 EDT
Description of problem:
Currently we've got quite many kernel args and even more kernel args are required if an automatic installation is performed (like in automated testing).
The number of required/default kernel arguments should be reduce (e.g. removing the iso name) to allow the addition of additional arguments (like for creating specififc sawp partitions etc)
Comment 1 Fabian Deutsch 2012-06-14 05:13:12 EDT
What I missed: This isn't a problem for an ISO but when bootign via PXE.
Comment 2 Mike Burns 2012-06-15 05:34:42 EDT
What are you proposing here?
Comment 3 Fabian Deutsch 2012-06-15 06:16:41 EDT
Some functionality to pass the informations we need to auto-install/configure the node on a way different from kargs.

<mburns> fabiand: number of kargs -- yes, it's a problem, but it's really bigger than that
<mburns> we need something different than kargs
<fabiand> mburns, something like ks :)
<mburns> either kickstart functionality or something similar
<fabiand> a file defining stuff that can be defined
<fabiand> yep
<mburns> fabiand: exactly
<mburns> something like passing /etc/default/ovirt
Comment 4 Fabian Deutsch 2012-07-23 06:13:22 EDT
I see two obvious ways of implementing this:

1. Pass an URL where to fetch the contents of /etc/default/ovirt

2. Pass an URL where to fetch the variables formatted as kernel arguments

I'm currently favoring the second solution because it can be implemented without changing much code and established code paths would be reused to transform the arguments into the appropriate /etc/default/ovirt file.

Sometimes, like in the case of BOOTIF, there is not just a 1:1 mapping between the KARG and a oVirt Node variable, but there also additional logic happening when the kargs are parsed. We would have to introduce some mechanism to run this logic when we are not using the kargs for all arguments.

Or am I wrong in my last point?
Comment 5 Fabian Deutsch 2013-11-28 10:12:27 EST
We should investigate which arguments can be dropped from the default cmdline.
Comment 6 Sandro Bonazzola 2014-03-04 04:17:44 EST
This is an automated message.
Re-targeting all non-blocker bugs still open on 3.4.0 to 3.4.1.
Comment 7 Fabian Deutsch 2014-04-30 07:44:42 EDT
This needs to be addressed differently.
The basic problem i sthat the management on the kargs on the server side is not solved.

This is up to confmgmt systems like Foreman, to keep track of the right args.

Node should not provide it's own mechanism to organize kargs on the server side.

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