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

[Louis Bouchard]

Blueprint changed by Louis Bouchard:

Whiteboard changed:
  User Stories:
  
  Risks:
  
  Test Plans:
  
  Release Note:
  
  ----------
  
  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
+     - 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
-  
+ 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
+     - 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?)
+     - 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
+ 
+ Notes:
+ MIR is not required for kdump-tools as its source package (makedumpfile) is already in main

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