support kernel arguments

[cgwalters]

We landed a lot of good work in rpm-ostree kargs. What we need to do is wrap that in MachineConfigs. One decision point is whether this is an extension to Ignition (if specified then does Ignition reboot?). Or is it a new item in the MachineConfig spec itself?

And the MCD would need to understand how to reconcile the user-specified kargs versus what's the default.

[mrguitar]

@runcom ^^

[cgwalters]

A lot of discussion around this; see this pivot discussion.

One thing that seems increasingly clear is that we should use MachineConfig as a "sugar" for Ignition where it makes sense.

IOW, we start from this:

diff --git a/pkg/apis/machineconfiguration.openshift.io/v1/types.go b/pkg/apis/machineconfiguration.openshift.io/v1/types.go
index f7df1d5..318506c 100644
--- a/pkg/apis/machineconfiguration.openshift.io/v1/types.go
+++ b/pkg/apis/machineconfiguration.openshift.io/v1/types.go
@@ -226,6 +226,8 @@ type MachineConfig struct {
 
 // MachineConfigSpec is the for MachineConfig
 type MachineConfigSpec struct {
+	// KernelArguments defines additional kernel arguments beyond the host defaults.
+	KernelArguments []string `json:"kernelArguments"`
 	// OSImageURL specifies the remote location that will be used to
 	// fetch the OS.
 	OSImageURL string `json:"osImageURL"`

[runcom]

One thing that seems increasingly clear is that we should use MachineConfig as a "sugar" for Ignition where it makes sense.

cannot agree more with this...

[cgwalters]

With coreos/rpm-ostree#1802

the MCD in upgrade.go when detecting a diff between the current/target KernelArgs would first call --remove on the old ones, then --add for the new ones.

There's an alternative implementation path where the MCD reads the BLS config performs the diff internally, and calls the appropriate rpm-ostree kargs invocation.

[runcom]

With projectatomic/rpm-ostree#1802

the MCD in upgrade.go when detecting a diff between the current/target KernelArgs would first call --remove on the old ones, then --add for the new ones.

if coreos/rpm-ostree#1802 provides a way to achieve the above it would be my preferred way.
We still need to decide on where to put Kargs (MC vs CRD vs something higher level?)

[runcom]

been thinking about this...do we want Kargs to be a list of "changes" over the current kargs on a boot? I suppose so, but we need to have some sort of syntax to describe that in the CRD or whatever. Also --append vs --replace should be something to take into account as well. Moreover, if we're supporting --delete we need to blacklist from removing kargs like ignition.platform and the like I guess.

[runcom]

also, for fips we need to also specify boot:

we require the ability to configure "fips=1" and "boot=UUID=" in order to successfully configure FIPS.

uuid=$(findmnt -no uuid /boot)
[[ -n $uuid ]] && echo $uuid

Last one for now, do we do this early pivot or day-2? both? (probably both, just triple checking)

[pliurh]

Can we also support this feature in RHEL based cluster? I think it would be great, if MCO can expose the same API for all the operating systems we support. So that, users don't have to implement other automation solution by their own, and it would also be beneficial for other component which relay on this feature, to work cross the operating systems.

[cgwalters]

Can we also support this feature in RHEL based cluster?

Probably. I bet it wouldn't be hard at all, but I'd like to land the feature for RHCOS first.