On 03/19/2014 04:45 PM, Martin Perina wrote:
Marek,
as one of fence-agents package maintainers can you comment this? Which way do you
prefer:
1) Add /etc/fence_kdump and /etc/fence_kdump_nodes to fence-agent-kdump package
and modify fence_kdump_send to read config and nodes from those files
2) Or add fence_kdump options and nodes directives to kdump.conf?
I will prefer
second options. Fence agents do not use config files at all
m,
Thanks
Martin Perina
----- Original Message -----
> From: "Vivek Goyal" <vgoyal(a)redhat.com>
> To: "Martin Perina" <mperina(a)redhat.com>
> Cc: kexec(a)lists.fedoraproject.org
> Sent: Wednesday, March 19, 2014 4:06:24 PM
> Subject: Re: [PATCH 1/5] fence_kdump configuration should be in one directory
>
> On Sun, Mar 16, 2014 at 09:41:26AM -0400, Martin Perina wrote:
>>
>> ----- Original Message -----
>>> From: "Vivek Goyal" <vgoyal(a)redhat.com>
>>> To: "Martin Perina" <mperina(a)redhat.com>
>>> Cc: kexec(a)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
>