scripts/coreos-fips: Add bootcfg switch for updating kargs

[ashcrow]

Since MCO handles kernel args now, default to setting up fips for everything BUT the kernel arguments. A new switch of --bootcfg has been added to allow a manual run where the kernel arguments are added by the script itself.

[ashcrow]

/assign @darkmuggle @runcom

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ashcrow

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [ashcrow]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ashcrow]

/cc @darkmuggle @runcom

[cgwalters]

Hmm...I'm not sure this really helps anything if we're going down the path of having a FIPS flag in MachineConfig. It doesn't ultimately matter too much if the MCD directly invokes rpm-ostree or indirectly from another script I'd say.

[cgwalters]

See openshift/machine-config-operator#800

[cgwalters]

To elaborate/rephrase...in openshift/machine-config-operator#388 I was arguing the MCO should be the sole thing owning kernel arguments as anything else would get into race conditions and reboot handling etc.

But conceptually this script is a part of the MCO. If we soon start shipping the MCD as part of the base OS, then the script could literally live in the MCO git repo too.

[ashcrow]

To elaborate/rephrase...in openshift/machine-config-operator#388 I was arguing the MCO should be the sole thing owning kernel arguments as anything else would get into race conditions and reboot handling etc.

👍 💯

But conceptually this script is a part of the MCO. If we soon start shipping the MCD as part of the base OS, then the script could literally live in the MCO git repo too.

I could see that.

[ashcrow]

@cgwalters I'm fine with NOT merging this PR if we want to keep this script as the owner of the kernel arguments. My understanding from @runcom was that we didn't want the script to own that part though.

[runcom]

My understanding from @runcom was that we didn't want the script to own that part though.

yeah that was my understanding as well but since #2 (comment) I believe that's better

[ashcrow]

OK. I'll close this PR then and we can allow this script to own the kernel arg change as it does today.