Limit processor unsupported type 'test' on upgrade v4.4.6 to v5.0

[adrialla]

When upgrading from perfsonar 4.4.6-1.el7 to version 5.0.0-0.b1.1.el7 the test results section shows no data (No data available in table).
pscheduler troubleshoot shows that limits fails:

Measuring MTU... 65535 (Local)
Looking for pScheduler... OK.
Fetching API level... 5
Checking clock... OK.
Exercising API... Archivers... Clock... Contexts... Tests... Tools... OK.
Fetching service status... OK.
Checking services... Ticker... Scheduler... Runner... Archiver... OK.
Checking limits... Failed.

Limit processor is not initialized: Limit 'idleex-default' has unsupported type 'test'

from the logs the error shows the same:

pfs-node journal: pscheduler-api[1754] CRITICAL Failed to load limit file: Limit 'idleex-default' has unsupported type 'test'

This happens only when upgrading from 4.4 to 5.0, not for fresh install of 5.0.

[igarny]

The problem is that declarations from old Limit's format are staying present. Even the stock configuration from 4.4.6 is not converted. (see below)

We need a way of notification to the system owner / admin especially for the Toolkit release, where people tend to rely solely on the GUI.

So a GUI alert is probably a good approach

	{
            "#": "This prevents denial of service by scheduling long tasks.",
	    "name": "idleex-default",
	    "description": "Default limits for idleex",
	    "type": "test",
	    "data": {
		"test": "idleex",
		"limit": {
		    "duration": {
                        "range": {
                            "lower": "PT1S",
                            "upper": "PT2S"
                        }
                     }
		}
	    }

[mfeit-internet2]

This has been in the documentation for three years:

NOTE: This limit type is considered deprecated and will be removed in a future release. Use the jq limit instead.

5.0 is that release. If you're using a custom limit configuration, you'll either need to adjust it to not use the test limit or switch to the configuration that ships with 5.0.

[laeti-tia]

The difference here is that it's not a custom limit. It's a stock 4.4.6 install that is directly upgraded to 5.0-beta. I think that in this case, we should just replace the 4.4.6 limits file with the 5.0 one. Nothing will be lost and full functionality will be preserved after the upgrade.

When people have modified it, yes, we can just have the package manager (apt or yum) notify the admin that the old limits file is kept and then it's up to the admin to reconcile the old and the new one.

[igarny]

I would like to make a wish also here....on behalf of the users.
How about having a CLI command, that highlights / exposes the faulty configuration to the user with the respective line numbers..
Perhaps later this info could be exported to the GUI

[mfeit-internet2]

If it's the stock limit config, it should be upgraded; that wasn't specified initially.

What OS Is this? The RPMs should replace a stock config automatically; Debian doesn't have a feature to do that and we'll have to add a bit of script to do that. In either case, this ticket should be migrated to the toolkit, which is where that's handled.

@igarny There is a CLI validator for the limit config. The JSON parser doesn't preserve information about line numbers, but most errors indicate where in the object tree it occurred.

[adrialla]

After upgrade the error is not showing any more. tested it with a fresh install of 4.4 and upgrade to latest and there where no errors.