Kdump (kernel crash dump) redesign

[garrett]

I'm currently working on a Kdump redesign. And thought having a discussion about it would be useful.

Right now, we have discussion happening on a a pull request, but I'd like for the discussion to continue after the PR is merge. Hence, opening it up here.

---

The discussion:

@liutgnu from the kdump team started it @ #19107 (comment):

Hi skobyda,

I'm Tao Liu from kdump team, came from bz2215024. Thanks a lot for your efforts on this. Since cockpit support is one subtask of bz2215024, and I have worked on the TUI part for sometime, I can share some of my thoughts:

1. It will be better to have an automatic test check mechanism, as @marusak pointed out, after machine reboot and user re-enter the kdump page, a sign indicating if the test is successful or not will be good. Relying on user himself to check if the "test vmcore" been generated is inconvenient, there might be plenty of vmcores located in a nfs/ssh server for "nfs/ssh kdump", the manual checking will be a boring work.

2. It may not be the final desgin, I planed to introduce 2 new shell command line options for kdumpctl: "kdumpctl test" and "kdumpctl test-check". "kdumpctl test" will generate a timestamp, which will be used to mark the vmcore that it belongs to a specifc test. "kdumpctl test-check" will check the kdump folder after reboot back, no matter if it's a local folder or a nfs/ssh remote folder, to see a vmcore with the specific timestamp string exist or not, which then be the indicator of the test is successful or not. Maybe you can call "kdumpctl test-check" in cockpit if it is easier.

3. If the user modifies the configuration file of kdump, the prior test result will be invalid and notify he should retest based on the current kdump config. I hadn't figure out the tech details, maybe some file monitor service to be involved.

Anyway, it's currently an early design phase for me, we can share thoughts or discuss kdump APIs if you need some underlying support.

And then @skobyda (basically) agreed with all the points @ #19107 (comment)

Then @liutgnu added:

OK, I will try to design the kdumpctl APIs in consideration of cockpit, hope it can be clean and easy to use. Just FYI, there is the repo which we used for implementing TUI "kdumpctl test/test-check" etc, currently just a POC in the ltao-dev branch.

And then I chimed in with more mockups @ #19107 (comment) (some other mockups are above in that PR, for the test crash confirmation modal).

[garrett]

Current WIP mockup:

It's still lacking a lot, such as: the modals for each option, the alert for when the service is out of sync (that is: if it's enabled and the service isn't running), other error cases, etc. — but the bulk of the direction to modernize the Kdump page (and bring it up to established patterns in both Cockpit and PatternFly) is there.

Source: Kdump.penpot in Kdump.zip (to be imported in Penpot)

I'll work on refining it and adding more soon.

[skobyda]

Putting here newer mockup with me and @garrett discussed privately on Matrix:

This iteration doesn't implement history of kernel crashes, as that might be too complex to figure out. Instead it contains the Status feature will be able to detect if kdump configuration is up to date and if test of its configuration went succesfully. This feature was described at #19107 (comment) .

[liutgnu]

Hi @garrett @skobyda,

Sorry for the late response. I'd like to share the working status about kdumpctl test/test-check.

I have planed to provide a simple interface from kexec-tools side as kdumpctl test/test-check as I mentioned previously. However after discussion, there is a trend for kexec-tools to be decoupled into sub-packages1, so people don't like the idea to integrate more code into kexec-tools. Since kdumpctl test/test-check is not a functional feature, but a user experience feature. So I re-designed the test/test-check code by creating a new independent repo 2, and the interface will be changed into "kdump-test test/test-check".

"kdump-test test" will trigger a real kernel crash and dump, and "kdump-test test-check" will actually check if there is vmcore generated specifically for this test, it will automatically mount/ssh if the dump target is a remote fs based on kdump.conf, and give test result as "test successful" or "test failed". Only the "test successful" kdump configs can be regarded as valid.

If cockpit will continue to use the test/test-check interface, there will be an issue of cockpit how to integrate the kdump-test source code. Because we don't plan to make the new repo a rpm package to maintain for it is too small and simple. Cockpit can call test/test-check by invoke command line as "curl https://raw.githubusercontent.com/rhkdump/kdump-test/master/kdump-test{-lib.sh,} | bash -s test/test-check", instead of the previous "kdumpctl test/test-check". But it requires external network access, so it may be unfriendly for cases which can only access to internal netwok.

Anyway, this is not a final design and I'd like to hear your suggestions and comments if you are still interested in test/test-check interface.

Thanks,
Tao Liu