Skip to content

Removal of the test Limit

Mark Feit edited this page Jan 24, 2022 · 2 revisions

What is Happening?

All support for the test limit type is being removed in perfSONAR 5.0.

One of the changes in perfSONAR 4.4 was the deprecation of pScheduler's test limit. This allowed creating limits based on test parameters. Secondarily, it carried through a feature from BWCTL that let throughput tests infer a maximum bandwidth based on what limits a proposed test passed. The internal mechanism for this was somewhat complicated and had an impact on tool plugin development. It also sometimes made the effects opaque in that there would be no diagnostic indication that bandwidth was being capped by the tool rather than the network. After nearly five years in production, it’s time to move on from that.

This change does not reduce pScheduler’s capabilities. As described below, limiting based on test parameters is still possible using the “jq” limit. Making on-the-fly changes to test parameters is better done with the rewriter, which can document what it did.

How Do I Adapt to This Change?

If you run a perfSONAR toolkit system as-shipped (i.e., with no customizations to /etc/pscheduler/limits.conf), no action is required. The upgrade to 5.0 will automatically replace the configuration with one that has been corrected.

If you have a customized limits.conf, any use of the test limit will need to be removed. It can be replaced by using the rewriter to force default test parameter values and the jq limit to enforce limits.

The limit configuration that will ship with perfSONAR 5.0 can be downloaded here. The specific changes from the prior versions can be viewed here. This file is fully-compatible with pScheduler 4.4 and may be used as a guide for preparing a custom configuration for use with 5.0. Note that there was a small correction for buggy behavior, so make sure that's incorporated.

Using the Rewriter to Set Default Values

Where the throughput tools used to infer a default value for the bandwidth parameter based on the limits passed, that process must now take place explicitly in the limit configuration using the rewriter.

This is an example segment of the rewrite section that would carry out that operation:

...
# Force default bandwidth for non-friendly requesters to 50 Mb/s
| if .test.type == "throughput"
    and .test.spec.bandwidth == null
    and (classifiers | contains(["friendlies"]) | not)
  then
    .test.spec.bandwidth = 50000000 | change("Capped bandwidth at 50 Mb/s")
  else
    .
  end

Using the jq limit to Restrict Test Parameters

This is an example of how to prevent throughput tests at any rate above 10 Gb/s using the jq limit instead of the test limit:

{
    "name": "throughput-max-bandwidth",
    "description": "Throughput maximum bandwidth (10 Gb/s)",
    "type": "jq",
    "data": {
        "script": [
            "import \"pscheduler/iso8601\" as iso;",
            "if .test.type == \"throughput\"",
            "   and (.test.spec.bandwidth == null or.test.spec.bandwidth > 10000000000)",
            "then",
            "  \"Throughput bandwidth must be less than 10 Gb/s\"",
            "else true",
            "end"
        ]
    }
}