[PATCH 1/5] fence_kdump configuration should be in one directory

[Vivek Goyal]

On Sun, Mar 16, 2014 at 09:41:26AM -0400, Martin Perina wrote:
> 
> 
> ----- Original Message -----
> > From: "Vivek Goyal" <vgoyal at redhat.com>
> > To: "Martin Perina" <mperina at redhat.com>
> > Cc: kexec at lists.fedoraproject.org
> > Sent: Friday, March 14, 2014 10:33:30 PM
> > Subject: Re: [PATCH 1/5] fence_kdump configuration should be in one directory
> > 
> > On Fri, Mar 14, 2014 at 11:18:06AM +0100, Martin Perina wrote:
> > > fence_kdump configuration and list of nodes should be in the same
> > > directory:
> > > 
> > >   /etc/sysconfig/fence_kdump
> > 
> > Thinking more about these files.
> > 
> > This is a general question for anybody who can answer. So which package
> > owns fence_kdump file?
> > 
> > IIUC, nobody owns it and current uderstanding seems to be that a user
> > will drop fence_kdump file and any fence_kdump_send options in there.
> > 
> > I think it is a bad idea. If fence_kdump_send needs options, then it
> > probably should create this config file and own it.
> > 
> > >   /etc/sysconfig/fence_kdump_nodes
> > 
> > And which package will own this file? Again looks like nobody.
> > 
> > I don't think we can go about dumping files in /etc/ and /etc/sysconfig
> > which are not owned by any package.
> 
> Package fence-agents-kdump contains only binaries and man pages. It doesn't
> contain any configuration since these binaries (especially fence_kdump_send)
> are completely useless without kexec-tools. You can look at fence_kdump_send
> binary as some kind of extension (plugin) of kdump functionality. So IMO
> there are 3 options:
> 
>  1) Include options for fence_kdump_send into kdump.conf
>       - I don't think this is a good idea, since fence_kdump_send is not
>         a core functionality of kdump

I think this is a reasonable option. We already have something to
pass options to dracut. Look at "dracut_args". We don't own dracut either
but we use dracut to generate initramfs and allow user to pass additional
options to dracut.

Doing something similar for passing arguments to fence_dump_send makes
sense to me. Say introduce another kdump.conf option "fence_kdump_send_opts".


Or fence_kdump_send should provide a config file where user can specify
all the options and fence_kdump_send reads that file at execution time.
 
> 
>  2) Read predefined user config files as a part of kdump configuration
>       - This is what this patch series propose
>       - IMO this is the best option

This does not address the issue of a config file present in /etc/ which is
not owned by any package?

And kexec-tools should not own the config file for fence-agent-kdump
package.

So if a config file has to be used for passing options, then it needs
to be owned by fence-agents-kdump package. Otherwise we should introduce
another option in kdump.conf to pass options to fence_kdump_send.
 
> 
>  3) Ignore fence_kdump_send completely
>       - Using this you are forcing anybody who want to use it as part of kdump
>         flow to modify parts of kexec-tools package after installation
>       - IMO this we should NEVER do
> 
> > 
> > I guess we need to then go back to the idea of invoking some kind of
> > tool which can give a list of nodes or retrieve a file containing
> > nodes or whatever.
> > 
> > Or vdsm package can own a config file which is present somewhere in
> > the system say /var/vdsm/list-of-nodes.
> 
> If you really want to do this, we can, but you will introduce another dependency
> to external application into kexec-tools. And if/when some other application
> would like to use fence_kdump you will read for config file from another
> place? Wouldn't this approach introduce too complex code instead of clear API?

Agreed. Trying to read config file generated by some other app is not
a good idea.
> 
> API:
> 
>    If /usr/libexec/fence_kdump_send is executable and /etc/sysconfig/fence_kdump_nodes
>    exists, configure fence_kdump functionality during reconfiguration of kdump (ie
>    after executing "kdumpctl restart")
> 
> Maybe even Pacemaker team could use this API instead its own proprietary ...

Creating a file where a list of nodes goes sounds good. Only thing
troubling me who is going to own the file which contains the list of
nodes.

I personally see only two options.

- fence-agents-kdump packages owns this node list file and reads this file
  during command invocation to determine the nodes.

- kexec-tools packages provides a config file where one can dump the list
  of nodes to send notifications to.

I am leaning towards that fence_kdump_send should provide a mode where
it reads options as well as list of nodes from files and
fence-agents-kdump packages owns these files.

And then pcs cluster should use the same API. Generate list of nodes and
save in the respective config file. If list of nodes changes, then create
a mechanism to regenerate the list and restart kdump service.

Generally tools don't provide commnad line option as well as read from
config files option but I think fence_kdump_send is little peculiar in
the sense that it can't be used as stand alone tool. And it does require
quite some amount of configuration. Now passing all that configuaration
responsibility to kdump seems overkill.

Kdump will read the nodes file and do the right thing to configure
repsective network or interface configuration.

Thanks
Vivek