manifest: add kexec-tools for kdump

[jlebon]

This was discussed in:
coreos/fedora-coreos-tracker#622

[jlebon]

Similar deps to those described in coreos/fedora-coreos-config#708:

Added:
  dracut-squash-049-75.git20200422.el8.x86_64
  ethtool-2:5.0-2.el8.x86_64
  kexec-tools-2.0.20-14.el8.x86_64
  lzo-2.08-14.el8.x86_64
  snappy-1.1.7-5.el8.x86_64
  squashfs-tools-4.3-19.el8.x86_64

This brings in lzo, which was already in FCOS but not yet in RHCOS.

/hold
while I sanity-check this locally.

[cgwalters]

Not opposed to this but I'd like to see at least some minimal investigation of why the heck it depends on dracut-squash for example.

[jlebon]

Not opposed to this but I'd like to see at least some minimal investigation of why the heck it depends on dracut-squash for example.

Did you see coreos/fedora-coreos-config#708?

[jlebon]

OK, dropping hold on this!
/hold cancel

[ashcrow]

This change looks good to my eyes BUT it may be something that makes more sense in extensions for OCP/RHCOS. If I remember correctly having kdump on the host but not in use can be a problem for some audits. cc'ing @JAORMX to jog my memory 😄

[JAORMX]

I agree with @ashcrow , seems to me like this would be more appropraite in extensions. For compliance, folks are required to disable kdump in their deployments with the following rationale:

Kernel core dumps may contain the full contents of system memory at the time of the crash. Kernel core dumps consume a considerable amount of disk space and may result in denial of service by exhausting the available space on the target file system partition. Unless the system is used for kernel development or testing, there is little need to run the kdump service.

[cgwalters]

Ahh I hadn't realized there was a compliance angle to this.

Well, currently today RHCOS just inherits the "bootable-rpm-ostree.yaml" bits so adding it to FCOS doesn't preclude doing it via an extension for RHCOS.

That said:

Unless the system is used for kernel development or testing, there is little need to run the kdump service.

Note that kdump.service won't (shouldn't) run by default unless the crashkernel= argument is provided...hm actually I think it really should have ConditionKernelCommandLine=crashkernel.

IOW while it's installed by default it won't be enabled by default on FCOS, and a compliance system can easily check this.

[jlebon]

Not against having it as an extension in RHCOS. This PR comes out of rough agreement from the team to have it baked in to reduce friction in enabling what we want to consider an important host feature. In pure FCOS, this means one less reboot. In OCP/OKD however, because the host always incurs a reboot, having it as an extension is actually not much more expensive. But diverging from FCOS has downsides as well, esp. around test sharing.

FWIW, I can imagine FCOS eventually removing it from the host and making it an extension in the future once we have "live extensions" (which don't require reboots).

But anyway, as Colin said, this wouldn't be enabled by default (and in fact, this PR adds a preset exactly to revert that).

[ashcrow]

Let's ensure this continues to be disabled by default and we can look at extensions later.

[cgwalters]

(and in fact, this PR adds a preset exactly to revert that).

Ahh I had missed that. But then, why does the preset enable it by default? Hmm well I guess that'd break existing users.

Does my suggestion

hm actually I think it really should have ConditionKernelCommandLine=crashkernel

seem right? Then we wouldn't need a preset override, it'd be "enabled by conditionally off".

[jlebon]

Does my suggestion

hm actually I think it really should have ConditionKernelCommandLine=crashkernel

seem right? Then we wouldn't need a preset override, it'd be "enabled by conditionally off".

I think so. Let's see what the maintainers say: https://src.fedoraproject.org/rpms/kexec-tools/pull-request/5

[miabbott]

/approve

[cgwalters]

/approve
Do we feel the compliance angle is resolved?
/assign ashcrow
for the lgtm based on that

[JAORMX]

/approve
Do we feel the compliance angle is resolved?
/assign ashcrow
for the lgtm based on that

Yep. As long as its not enabled by default it should be fine.

[cgwalters]

Yep. As long as its not enabled by default it should be fine.

👍

So on that note...we could add something to tests/kola/misc-ro/misc-ro.sh

[ashcrow]

/lgtm

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ashcrow, cgwalters, jlebon, miabbott

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [ashcrow,cgwalters,jlebon,miabbott]

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

[jlebon]

So on that note...we could add something to tests/kola/misc-ro/misc-ro.sh

Let's do FCOS first, then we can copy/paste into RHCOS: coreos/fedora-coreos-config#716