[Blueprint servercloud-r-kdump-tool] Enable kdump mechanism from kdump-tool instead of kexec-tools

[Chris J Arges]

Blueprint changed by Chris J Arges:

Whiteboard changed:
  User Stories:
  
  Risks:
  
  Test Plans:
  
  Release Note:
  
+ ----------
  
- [louis_bouchard] - kdump-tools needs to be MIR / file a bug: TODO
- [smb] - discuss linuxcrashdump changes on ubuntu-devel / ubuntu-kernel: TODO
- [smb] - linuxcrashdump changed to install kdump-tool (after discussion): BLOCKED
- [christopherarges] - write better documentation for kdump-tool: TODO
- [dannf] - validate/invalidate with kdump-tools / mkdumpfile on ARM: TODO
- [louis_bouchard] - Integrate netdump support: POSTPONED
- [med] - netdump charm to aggregate dumps in a cloud: TODO
+ The kdump mechanism from the kdump-tool package is more flexible than
+ its kexec-tool equivalent. It allows for multiple dumps to be collected,
+ is the mechanism used in upstream Debian and has a configuration file
+ that let the sysadmin controls some parameters.
+ 
+ It is currently functional on Ubuntu but the documented way of gathering
+ a kernel dump is to use the 0_kdump initscript delivered by kexec-tools
+ which package the kernel dump file as an Apport bundle. While this
+ solution is sufficient on Desktops, it becomes restrictive on
+ server/cloud installs.
+ 
+ Rationale: Current kexec-tool kernel dump capture mechanism is too
+ limitative in a server/cloud environment. Because you only capture last
+ crash; people want to change mkdumpfile options, have to hack scripts
+ vs. conf files.
+ 
+ We might need to consider different use cases for desktop/server if
+ using kdump-tool. But this might not be bad since we can have a similar
+ setup as kexec-tool.
+ 
+ linux-crashdump
+     - needs to be changed to install kdump-tool
+     - does it need to install 'crash'? we might not do analysis on same machine
+ 
+ Goal: Decide on the feasibility of using kdump-tool as default for server/cloud installs
+  
+ Issues :
+ what is the current story around kdump with UEFI ?
+     - currently disabled if using secure boot
+     - but will be re-enabled when we can use signed kexec kernels
+ Is the "server only" requirement valid or should we use kdump accross the board ?
+ Is usage of apport hooks for kernel dumps useful and/or valid ?
+ 
+ Need to be considerate of
+     - whoopise integration (how is this turned on for servers?)
+     - private data reporting (private daisy instance?)
+ 
+ Can server/cloud users upload large amounts of crash data?; need to
+ consider sensitive environments, etc.
+ 
+ Discussion points:
+ Right now start with x86, long term ensure it works on ARM.
+ consider how we can reproduce apport behavor with kdump-tools during discussion.
+ need to determine use cases for desktop/server for kdump-tool configurations

-- 
Enable kdump mechanism from kdump-tool instead of kexec-tools
https://blueprints.launchpad.net/ubuntu/+spec/servercloud-r-kdump-tool