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

[Marek Grac]

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 at redhat.com>
>> To: "Martin Perina" <mperina at redhat.com>
>> Cc: kexec at 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 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
>>