[PATCH 1/6] fence_kdump for generic clusters v3: Rename FENCE_KDUMP_CONFIG to FENCE_KDUMP_CONFIG_FILE

[Martin Perina]

----- Original Message -----
> From: "Vivek Goyal" <vgoyal at redhat.com>
> To: "Martin Perina" <mperina at redhat.com>
> Cc: kexec at lists.fedoraproject.org
> Sent: Thursday, March 27, 2014 8:14:32 PM
> Subject: Re: [PATCH 1/6] fence_kdump for generic clusters v3: Rename FENCE_KDUMP_CONFIG to FENCE_KDUMP_CONFIG_FILE
> 
> On Wed, Mar 26, 2014 at 10:24:07AM +0100, Martin Perina wrote:
> > Bug-Url: https://bugzilla.redhat.com/1079821
> > Signed-off-by: Martin Perina <mperina at redhat.com>
> 
> Can you provide changelog explaining what this patch is doing. We put
> appropriate changelog for every patch in the series.

Vivek, what kind of changelog do you mean?

This is what I see on my git using git log:

commit b730272fb04de04f770cbfb9b6afc15dcfcbbcbd
Author: Martin Perina <mperina at redhat.com>
Date:   Tue Mar 25 12:33:04 2014 +0100

    Rename FENCE_KDUMP_CONFIG to FENCE_KDUMP_CONFIG_FILE
    
    Bug-Url: https://bugzilla.redhat.com/1078134
    Signed-off-by: Martin Perina <mperina at redhat.com>

And this content is also included in the email. Or do you think,
that "Rename FENCE_KDUMP_CONFIG to FENCE_KDUMP_CONFIG_FILE" is not
descriptive enaough?

> 
> Also in general, have you tested it? Last time you mentioned that from
> vdsm side you folks are still debating which method to use. I am assuming
> that means vdsm code is not ready yet and that probably means this
> patchset might be untested?

I successfully test those patches using:

  1) Modify fence_kdump_nodes and fence_kdump_args in kdump.conf on host1
  2) Execute 'kdumpctl restart' on host1

  Above steps will be performed automatically by new VDSM module.

  Then I execute this test:

  1) I executed fence_kdump listener on host2 which is included in fence_kdump_nodes
  2) I crashed kernel on host1 using 'echo c > /proc/sysrq-trigger'
  3) I looked through IPMI to host1 console if kdump was executed sucessfully
  4) I verified that required notification was received in host2

I also verified that without specifying fence_kdump the kdump process will work
correctly.

I didn't test these patches with Pacemaker, but I think that once you will be
satisfied with content of those paches, we can ask some one from Pacemake team
to test them if those patches didn't create new regression.

Marek, do you agree?

> 
> [..]
> > -FENCE_KDUMP_CONFIG="/etc/sysconfig/fence_kdump"
> > +FENCE_KDUMP_CONFIG_FILE="/etc/sysconfig/fence_kdump"
> >  FENCE_KDUMP_SEND="/usr/libexec/fence_kdump_send"
> >  FENCE_KDUMP_NODES="/etc/fence_kdump_nodes"
> >  
> > diff --git a/kdumpctl b/kdumpctl
> > index 8d5498a..24fb988 100755
> > --- a/kdumpctl
> > +++ b/kdumpctl
> > @@ -249,8 +249,8 @@ function check_rebuild()
> >  	EXTRA_BINS="$EXTRA_BINS $CHECK_FILES"
> >  	files="$KDUMP_CONFIG_FILE $kdump_kernel $EXTRA_BINS"
> >  
> > -	if [ -f $FENCE_KDUMP_CONFIG ]; then
> > -		files="$files $FENCE_KDUMP_CONFIG"
> > +	if [ -f $FENCE_KDUMP_CONFIG_FILE ]; then
> > +		files="$files $FENCE_KDUMP_CONFIG_FILE"
> >  	fi
> 
> why don't we get rid of this fence kdump config file.  I thought we agreed
> that fence_kdump_send options will be specified in /etc/kdump.conf using
> a new option.
> 
> No package owns /etc/sysconfig/fence_kdump_send. So trying to retain
> it does not make sense.

As we agreed in previous email, current API for Pacemaker will be untouched.

So in following patches, I will introduce new options in kdump.conf. With those
patches kdump will not use /etc/fence_kdump_nodes file (this will be replaced
with fence_kdump_nodes option in kdump.conf). But not to break Pacemaker API
during Pacemaker fence_kdump configuration content of /etc/sysconfig/fence_kdump
will be read and store into fence_kdump_args in kdump.conf in initial ramdisk.