Add sugar for kdump configuration

[travier]

What are the configuration options for kdump?

Enabling kdump on FCOS (& RHCOS) requires:

• setting a kernel argument (for example: crashkernel=256M) which has a default suggested value;
• setting options in /etc/kdump.conf to configure where the coredump will be stored;
• setting options in /etc/sysconfig/kdump to configure additional kernel arguments passed to the "dump" kernel instance.
• enabling the kdump.service unit.

What would the sugar looks like?

From https://github.com/coreos/fedora-coreos-tracker/issues/622#issuecomment-694225598:

kdump:
  crashkernel: 128M
  kargs: foo=bar
  config: |
    net penguin.example.com:/export/cores

References

• RHEL 8 documentation for examples.
• See also initial discussion in https://github.com/coreos/fedora-coreos-tracker/issues/622.

[bgilbert]

• Rather than crashkernel: 128M, maybe something like reserved_mib: 128?
• Is it common to want to pass additional arguments to the dump kernel? Or can we let the user configure this themselves if they want it?

[travier]

• Rather than crashkernel: 128M, maybe something like reserved_mib: 128?

The full option syntax enables setting memory size dependent values and offset but I don't know if that's something we want to support.

• Is it common to want to pass additional arguments to the dump kernel? Or can we let the user configure this themselves if they want it?

I think this heavily depend on where the coredump will be stored as you might need to setup networking for the crash initrd.

[bgilbert]

The full option syntax enables setting memory size dependent values and offset but I don't know if that's something we want to support.

I suspect that's a pretty unusual setting. Users can always bypass the sugar and configure advanced settings manually.

I think this heavily depend on where the coredump will be stored as you might need to setup networking for the crash initrd.

Would it make sense to provide target-specific sugar?

kdump:
  reserved_mib: 128
  destinations:
    net:
      kernel_args: ip=X
      remotes:
        - penguin.example.com:/export/cores
    something-else: z

[kelvinfan001]

• Is it common to want to pass additional arguments to the dump kernel? Or can we let the user configure this themselves if they want it?

I think this heavily depend on where the coredump will be stored as you might need to setup networking for the crash initrd.

Looking at kdump.conf (config for kdumpctl) and /usr/bin/kdumpctl (executed by kdump.service), it doesn't seem like there is a way to configure the kargs passed to the crash kernel (via kdump); it looks like the kargs passed to the crash kernel are always the same. So I think that although kexec does support specifying kargs for the crash/second kernel, it might not be necessary for kdump to work.

[travier]

It looks like kdumpctl sources the content of /etc/sysconfig/kdump to setup kdump kernel kargs.

So I think that although kexec does support specifying kargs for the crash/second kernel, it might not be necessary for kdump to work.

I don't think this is required for kdump but someone might want to setup a custom networking configuration to bring only the internal network for example (and not the internet connected one) to save kdumps to an internal server as they may include sensitive data.

[travier]

I suspect that's a pretty unusual setting. Users can always bypass the sugar and configure advanced settings manually.

Agree.

I think this heavily depend on where the coredump will be stored as you might need to setup networking for the crash initrd.

Would it make sense to provide target-specific sugar?

AFAIK, the kdump.conf docs say that "only one dump target and path can be specified".

[kelvinfan001]

It looks like kdumpctl sources the content of /etc/sysconfig/kdump to setup kdump kernel kargs.

ahh you're right, I completely missed that. Sorry for the confusion!

[bgilbert]

Would it make sense to provide target-specific sugar?

AFAIK, the kdump.conf docs say that "only one dump target and path can be specified".

Ah, okay. Even so, it might be useful to abstract some of the low-level config file details.

[jlebon]

Enabling kdump on FCOS (& RHCOS) requires:

I think that list is also missing enabling kdump.service itself.

[hshiina]

Hi,

Is this work still required? Regarding OpenShift, Butane is available for configuring kdump since OpenShift 4.8 as in documentation. This doesn't look so complicated for those who want to enable kdump simply and looks flexible for those who want to customize the configuration by themselves.

I'm interested in this issue because I hope development of kdump for OpenShift will be completed and it will be fully available.

[bgilbert]

It's not required, and we can always add it later.

I'd note, though, that the linked example in OCP docs is not trivial. It has one service enablement, one karg, and two config files with different syntaxes and a bunch of boilerplate. This is exactly the sort of thing sugar can help simplify.

[travier]

I don't think this feature is required for kdump to be fully supported. However it would definitely help with UX as @bgilbert mentioned.

[bgilbert]

Is this something we still want to pursue?

[travier]

I'd say that it would be nice to have but it's low priority.