[ClusterLabs] FEEDBACK WANTED: possible deprecation of nagios-class resources

[Ken Gaillot]

On Fri, 2023-07-14 at 17:24 +0800, Mr.R wrote:
> Hi,
> 
> Thanks for your answer, it supplys some useful ideas about nagios.
> And, there are some questions that need to communicate.
> 
> 1. Is there a specific use case for bundle? No official use case has
> been found so far. Could you please provide it?

Bundles are the preferred method for launching containerized
applications.

A bundle lets you configure a single resource specifying the number of
container instances desired, whether they need individual IP addresses
and/or host storage, and the application to be monitored inside the
container. See:

https://clusterlabs.org/pacemaker/doc/2.1/Pacemaker_Explained/singlehtml/index.html#bundles-containerized-resources

> 
> 2. What are the nagios plugins that pacemaker has supported in the
> past?  As far as I know, there are only a few naigos plugins about
> network,like check_tcp, check_udp and so on. Are there any complex
> monitoring plugins such as databases or services? Could you please
> provide it? If not, will you consider adding something similar?

Pacemaker supports any nagios plugin, as long as a file is available
listing its options in OCF meta-data format. The nagios-plugins-
metadata project provides such files for many common plugins.

> If nagios is deprecated, are there any other scripts or templates
> that the community might develop for to monitor virtual machines's
> services or databases?

The ocf:pacemaker:VirtualDomain agent has a "monitor_scripts" parameter
that lets you provide arbitrary scripts to monitor whatever is inside
the virtual domain. The only requirement is that the scripts must exit
with zero status on success and nonzero on error. The scripts have
access to Pacemaker's environment variables, so they can get the
parameter values used by the agent.

That means you could write a trivial script that calls any nagios
plugin you want using the relevant parameters, then returns success or
failure.

> 
> thanks again.
> 
> >Hi,
> 
> >Thanks for the feedback, it's very helpful to hear about a real-
> world use case.
> 
> >At this point (and for any remaining 2.1 releases), the only effect
> is a warning in the logs when nagios resources are configured.
> Eventually (probably next year), there will be a 2.2.0 or 3.0.0
> release, and we can consider dropping support then.
> 
> >The idea was that since nagios resources were first introduced,
> better solutions (such as Pacemaker Remote and bundles) have emerged
> for particular use cases. Being able to reduce how much code needs to
> be maintained can be a big help to developers, so if the remaining
> use cases aren't widely needed, it can be worthwhile to drop support.
> 
> >The main use case where nagios resources can still be helpful is
> (as you mentioned) when a VM or container image can't be modified.
> 
> >The alternative would be to write a custom OCF agent for the
> image. Basically you could take the usual OCF agent (VirtualDomain,
> docker,podman, etc.) and change the monitor action to do whatever you
> want. If you have an existing nagios check, you could even just call
> that from the monitor action, so it would be just a few lines of
> coding.
> 
> >If custom agents are not convenient enough, we could consider "un-
> deprecating" nagios resources if there is demand to keep them.
-- 
Ken Gaillot <kgaillot at redhat.com>