[dpdk-ci] [RFC v2] Expected results JSON format

[Patrick MacArthur <pmacarth@iol.unh.edu>]

Hi, all,

Based on feedback and internal discussion that occurred after our
meeting this morning, this is the format that I am now expecting for
the results:

    {
      "environment": "https://dpdklab.iol.unh.edu/results/environments/9/",
      "results": [
        {
          "frame_size": 64,
          "txd/rxd": 1024,
          "throughput": {
            "result": "PASS",
            "delta": -0.452,
            "unit": "Mpps"
          }
        },
        /* ... */
      ]
    }

OR:

    {
      "environment": "https://dpdklab.iol.unh.edu/results/environments/9/",
      "results": [
        {
          "frame_size": 64,
          "txd/rxd": 1024,
          "throughput": {
            "result": "PASS",
            "actual": 45.783,
            "expected": 46.423,
            "unit": "Mpps"
          }
        },
        /* ... */
      ]
    }

The environment URL will be accessible via the CI_ENVIRONMENT_URL
environment variable passed to your script via Jenkins; in the
interest of making the results output self-describing, this should be
echoed back in the JSON response.

Each entry in the results list is essentially a table row. The
parameters "frame_size" and "txd/rxd" are the input parameters for
each given measurement; what I gave here is just an example.

If the vendor script provides a delta, that delta is the only thing
that will be stored in the database for that test case. If the vendor
script provides actual and expected values, the expected value and the
computed delta will be stored in the database.

Either way, as discussed on the call, the results database API will
have access control to only allow access to data from the respective
vendor's users. Note that while we will endeavor to make our access
control as secure as possible, there is some inherent risk in any
database of a leak. Vendors should be aware of this potential risk and
weigh the advantage of having the absolute measurements accessible to
them against this potential risk.

Thoughts/concerns?

Thanks,
Patrick

-- 
Patrick MacArthur
Research and Development, High Performance Networking and Storage
UNH InterOperability Laboratory