Rename nagios plugins to check_ma_*

[laeti-tia]

We got the following comment from one attendee to a perfSONAR workshop recently.

tl;dr

Use check_ma_ plugin name prefix, to "set them apart"

To "someone familiar with Nagios, but not perfSONAR": 'check_throughput' might be seen as an 'active' plugin which makes throughput measurements of it's own.

'check_ma_throughput' is readily identifiable as "something which uses 'ma' to do - whatever it does - to 'check throughput'"

---

Background:

The idea originates from many years of designing Nagios namespaces (check names, command names, service object definitions, even host object identifiers), where "brief identification" is important due to string length constraints (small terminals, narrow fields in webUIs etc).

Generally I have become accustomed to creating namespace identifiers of a 'left->right, general->specific' format somewhat similar to SNMP OID structures.

In the case of nagios plugins this translates into a general format of: check_<transport|method>_<item|object|type>_<...>

The concept is not mine, and I am not taking credit for it, but it really does make a lot of sense. This kind of naming results in natural grouping and ordering of similar/related plugins, such the 'ftp related' plugins listed here — to name a good example.

---

Suggestion:

In light of the above I propose a naming scheme of check_ma_<name>

This would clearly distinquish these plugins from "regular" plugins, while at the same time hinting at their use/function.

An added benefit of introducing this sort of naming scheme is a reduced risk of 'naming collisions'. Since these plugins may very well be installed on 'nagios-type' systems, they may very well find themselves in the company of a bunch of other plugins, and with generic terms as 'throughput', 'latency' etc there is a very real risk that other plugins exist with the same name.

That issue is sidestepped completely with the above naming scheme, and it therefore also allows software packages to install the plugins in the 'proper' $PluginPath on the destination, system with considerably reduced risk of package conflicts.

I realize that it takes some effort to rename existing pieces of code, but it is absolutely doable. And if it is to happen, then 'now' is a much much better time than 'later', because the number of 'measurement archives plugins' deployed will only increase over time.

[vvidic]

On Mon, Jun 25, 2018 at 05:05:31AM -0700, Antoine Delvaux wrote:

'check_ma_throughput' is readily identifiable as "something which uses 'ma' to do - whatever it does - to 'check throughput'"

Maybe check_perfsonar_throughput would be even better than using perfsonar specific MA acronym?

In any case we could use symlinks to preserve the old names for a release or two (if needed).

-- Valentin Vidic Computer Systems Engineer - Expert Department of Computer Infrastructure and Services Croatian Academic and Research Network - CARNET Josipa Marohnica 5, HR-10000 Zagreb, Croatia tel: +385 1 6661 714, fax. +385 1 6661 635 gsm: +385 91 2480 919 www.CARNet.hr

[jonclausen]

I was the one to suggest this change

Maybe check_perfsonar_throughput would be even better than using perfsonar specific MA acronym?

I would disagree: The general 'format' I was referring to in the original piece, has "transport" or "method" as the first qualifying component in the naming scheme. The reason I chose to suggest 'ma' is that the data source for these plugins is the Measurement Archive, and that is what matters in this context.

Also, it's a matter of brevity, since the name of the check may be subject to 'length constraints' imposed anywhere along the signal path to the end user.

The identifier I'm proposing is not meant to actually explain anything, it should just function as a 'flag':

When you know what it means, it's easily recognized - and if you don't, then it's simple to find out.

I don't personally think it's really needed, but two more characters might serve to make the identifier slightly more self explanatory - so:

"psma" for

Perf Sonar Measurements Archive

The main point is that the plugins are collecting data from the measurement archive(s) rather than actively doing measurements on their own, and that is what the naming should imply.

In any case we could use symlinks to preserve the old names for a release or two (if needed).

In my experience symlinks may introduce problems of their own, and they will generally just serve to postpone the 'surprise' of the change. In the software packages, the names of plugins will be well known, and it is a relatively trivial exercise to ensure that naming is consistent within the packaging scope. My main experience with packaging is 'rpm', and in that framework, setting up package dependencies and 'conflicts' to retire one file in favor of another is simple enough, although is does require attention to detail.

This leaves unpackaged 'consumers' of the plugins. These will generally be 'local' adaptations, which will require 'local' intervention regardless of time, purpose or 'mechanics'.

So my take on the situation goes something like this:

• I think it's a Good Idea (not surprising)
• there are challenges, but they are managable
• the benefits outweigh the challenges
• 'sooner' is better than 'later'