Hi,
After long discussion about fence_kdump config files (where those files should be located and which packages should own them) I propose this solution to support fence_kdump configuration for generic clusters:
- Add two new options to kdump.conf
fence_kdump_nodes - List of hosts separated by space to send fence_kdump notification to (this option is mandatory to enable fence_kdump)
fence_kdump_args - Command line arguments for fence_kdump_send (it can contain all valid arguments except hosts to send notification to)
- Modify kdump behavior due to new options
1) If fence_kdump_nodes option is set and fence_kdump_send is found and executable -> configure network for kdump and execute fence_kdump_send with those nodes (and also with args specified in fence_kdump_args if not empty)
2) If fence_kdump_nodes is not set, try to configure fence_kdump using cluster settings (current behavior). This should stay in kexec-tools not to break compatibility and can be removed after Pacemaker will start using new options.
Do you agree?
Martin Perina
On Tue, Mar 25, 2014 at 10:26:57AM -0400, Martin Perina wrote:
Hi,
After long discussion about fence_kdump config files (where those files should be located and which packages should own them) I propose this solution to support fence_kdump configuration for generic clusters:
Add two new options to kdump.conf
fence_kdump_nodes - List of hosts separated by space to send fence_kdump notification to (this option is mandatory to enable fence_kdump)
fence_kdump_args - Command line arguments for fence_kdump_send (it can contain all valid arguments except hosts to send notification to)
Modify kdump behavior due to new options
If fence_kdump_nodes option is set and fence_kdump_send is found and executable -> configure network for kdump and execute fence_kdump_send with those nodes (and also with args specified in fence_kdump_args if not empty)
If fence_kdump_nodes is not set, try to configure fence_kdump using cluster settings (current behavior). This should stay in kexec-tools not to break compatibility and can be removed after Pacemaker will start using new options.
Do you agree?
Above proposal sounds reasonable. So you will be modifying /etc/kdump.conf directly? And this will be done using some vdsm component present on the host?
Other option is to create new file for nodes and keep all configuration files in /etc/kdump. I am not sure if that approach has significant advantage over this one.
I guess to keep things simple, let us take this appraoch and we can always move to a file based config solution down the line in a backward compatible manner.
Thanks Vivek
----- Original Message -----
From: "Vivek Goyal" vgoyal@redhat.com To: "Martin Perina" mperina@redhat.com Cc: kexec@lists.fedoraproject.org, "Marek Grac" mgrac@redhat.com, "Barak Azulay" bazulay@redhat.com, "Itamar Heim" iheim@redhat.com Sent: Wednesday, March 26, 2014 5:37:55 PM Subject: Re: Add fence_kdump support for generic cluster v3
On Tue, Mar 25, 2014 at 10:26:57AM -0400, Martin Perina wrote:
Hi,
After long discussion about fence_kdump config files (where those files should be located and which packages should own them) I propose this solution to support fence_kdump configuration for generic clusters:
Add two new options to kdump.conf
fence_kdump_nodes - List of hosts separated by space to send fence_kdump notification to (this option is mandatory to enable fence_kdump)
fence_kdump_args - Command line arguments for fence_kdump_send (it can contain all valid arguments except hosts to send notification to)
Modify kdump behavior due to new options
If fence_kdump_nodes option is set and fence_kdump_send is found and executable -> configure network for kdump and execute fence_kdump_send with those nodes (and also with args specified in fence_kdump_args if not empty)
If fence_kdump_nodes is not set, try to configure fence_kdump using cluster settings (current behavior). This should stay in kexec-tools not to break compatibility and can be removed after Pacemaker will start using new options.
Do you agree?
Above proposal sounds reasonable. So you will be modifying /etc/kdump.conf directly? And this will be done using some vdsm component present on the host?
Yes, we will change fence_kdump_nodes and fence_kdump_args when needed and after the change we will call { kdumpctl | /etc/init.d/kdump } restart to rebuild initramfs.
Other option is to create new file for nodes and keep all configuration files in /etc/kdump. I am not sure if that approach has significant advantage over this one.
Do you mean to set into fence_kdump_nodes name of file which will contain actual list of nodes?
I guess to keep things simple, let us take this appraoch and we can always move to a file based config solution down the line in a backward compatible manner.
OK, patches I sent you for review using options described above ...
Thanks Vivek
On Wed, Mar 26, 2014 at 12:53:50PM -0400, Martin Perina wrote:
----- Original Message -----
From: "Vivek Goyal" vgoyal@redhat.com To: "Martin Perina" mperina@redhat.com Cc: kexec@lists.fedoraproject.org, "Marek Grac" mgrac@redhat.com, "Barak Azulay" bazulay@redhat.com, "Itamar Heim" iheim@redhat.com Sent: Wednesday, March 26, 2014 5:37:55 PM Subject: Re: Add fence_kdump support for generic cluster v3
On Tue, Mar 25, 2014 at 10:26:57AM -0400, Martin Perina wrote:
Hi,
After long discussion about fence_kdump config files (where those files should be located and which packages should own them) I propose this solution to support fence_kdump configuration for generic clusters:
Add two new options to kdump.conf
fence_kdump_nodes - List of hosts separated by space to send fence_kdump notification to (this option is mandatory to enable fence_kdump)
fence_kdump_args - Command line arguments for fence_kdump_send (it can contain all valid arguments except hosts to send notification to)
Modify kdump behavior due to new options
If fence_kdump_nodes option is set and fence_kdump_send is found and executable -> configure network for kdump and execute fence_kdump_send with those nodes (and also with args specified in fence_kdump_args if not empty)
If fence_kdump_nodes is not set, try to configure fence_kdump using cluster settings (current behavior). This should stay in kexec-tools not to break compatibility and can be removed after Pacemaker will start using new options.
Do you agree?
Above proposal sounds reasonable. So you will be modifying /etc/kdump.conf directly? And this will be done using some vdsm component present on the host?
Yes, we will change fence_kdump_nodes and fence_kdump_args when needed and after the change we will call { kdumpctl | /etc/init.d/kdump } restart to rebuild initramfs.
I think you should use "systemctl restart kdump" to restart kdump service after modifying /etc/kdump.conf.
Other option is to create new file for nodes and keep all configuration files in /etc/kdump. I am not sure if that approach has significant advantage over this one.
Do you mean to set into fence_kdump_nodes name of file which will contain actual list of nodes?
No. I think thiking of creating another config file just say /etc/kdump/fence_kdump_nodes and external utitlity could drop list of nodes there and kdump would read this file. But first we need to do some cleanup and move all kdump configuration files in /etc/kdump/.
Also we need to differentiate between default config files as delivered during package installation or upgrade and put them /lib/kdump/ and allow user to override default options using options in /etc/kdump/*.conf files.
I guess to keep things simple, let us take this appraoch and we can always move to a file based config solution down the line in a backward compatible manner.
OK, patches I sent you for review using options described above ...
I will review your patches soon.
Thanks Vivek
-
mperina＠redhat.com -
Vivek Goyal