[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:34:57 PM
> Subject: Re: [PATCH 1/6] fence_kdump for generic clusters v3: Rename FENCE_KDUMP_CONFIG to FENCE_KDUMP_CONFIG_FILE
> 
> On Thu, Mar 27, 2014 at 03:14:32PM -0400, Vivek Goyal wrote:
> > 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.
> > 
> > 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?
> > 
> > [..]
> > > -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.
> 
> We generate a kdump.conf internal to initramfs. We can start generating
> that file to put fence_kdump options and fence_kdump nodes in that file
> even for pacemaker.
> 
> So dracut-module-kdump.sh implementation will always expect that fence
> kdump optoins and nodes are passsed in /etc/kdump.conf.

Yes, that behavior is included in following patches.

> 
> It is only kdumpctl implementation which will look for these options in
> /etc/kdump.conf and if it is not there it will assume we are dealing
> with pacemaker and use existing code of pcs to get to list of nodes.

Yes

> 
> For fedora we can change options method even for pcs and now make it
> mandatory that fence kdump options need to be passed through
> /etc/kdump.conf file.
> 
> We should talk to pacemaker folks and figure out how can we pass
> nodes also using /etc/kdump.conf so that they also make use of this
> new API instead of kdump doing special processing for pcs.

Well, if you agree, I would prefer to get this generic API into Fedora 20
and RHEL 6.6 (as we need this to introduce fence_kdump support into oVirt/RHEVM
products during June/July) and once this new API is in, Pacemaker could prepare
new version, which will use this generic API. And after that we can drop old
Pacemaker API.

Marek, what do you think of this approach?