Clean up service-info based on AMED feedback

[jaeddy]

Branching this out as a separate issue from #122.

They did some cleanup work on /service-info and want to see what others think. Here is there service-info

{
  "supported_wes_versions": [
    "v1.0.0"
  ],
  "workflow_engines": [
    {
      "name": "cwltool",
      "version": "1.0.20181201184214",
      "workflow_types": [
        {
          "language_type": "CWL",
          "language_version": "v1.0"
        }
      ]
    }
  ],
  "auth_instructions_url": "https://dummy_auth_instructions_url/",
  "contact_info_url": "https://dummy_contact_info_url/"
}

Compared to the WES service-info:

{
  "workflow_type_versions": {
    "additionalProp1": {
      "workflow_type_version": [
        "string"
      ]
    },
    "additionalProp2": {
      "workflow_type_version": [
        "string"
      ]
    },
    "additionalProp3": {
      "workflow_type_version": [
        "string"
      ]
    }
  },
  "supported_wes_versions": [
    "string"
  ],
  "supported_filesystem_protocols": [
    "string"
  ],
  "workflow_engine_versions": {
    "additionalProp1": "string",
    "additionalProp2": "string",
    "additionalProp3": "string"
  },
  "default_workflow_engine_parameters": [
    {
      "name": "string",
      "type": "string",
      "default_value": "string"
    }
  ],
  "system_state_counts": {
    "additionalProp1": 0,
    "additionalProp2": 0,
    "additionalProp3": 0
  },
  "auth_instructions_url": "string",
  "contact_info_url": "string",
  "tags": {
    "additionalProp1": "string",
    "additionalProp2": "string",
    "additionalProp3": "string"
  }
}

So the additions they are looking for include:

CPU info, memory usage, and queue length (the last one is covered already)

Will address in a new feature branch.

[jaeddy]

A few other thoughts here:

{
  "supported_wes_versions": [
    "v1.0.0"
  ],

API version should be implicit in the WES server URL (e.g., ga4gh/wes/v1/); if a given server supports multiple versions/profiles for WES, they should effectively be considered separate endpoints (each nominally discoverable through the GA4GH Discovery API).

  "workflow_engines": [
    {
      "name": "cwltool",
      "version": "1.0.20181201184214",
      "workflow_types": [
        {
          "language_type": "CWL",
          "language_version": "v1.0"
        }
      ]
    }
  ],

I'd propose this as an alternative:

  "workflow_types": [
    {
      "language_type": "CWL",
      "language_version": "v1.0",
      "language_engine": {
        "name": "cwltool",
        "version": "1.0.20181201184214"
      }
    }
  ],

In other words, the WES client's primary concern is whether or not the endpoint supports the type and version of the workflow to be run. How the WES endpoint chooses to execute a supported workflow (i.e., via an installed, compatible engine) is potentially useful for transparency, but ultimately in the category of "nice to know."

  "auth_instructions_url": "https://dummy_auth_instructions_url/",
  "contact_info_url": "https://dummy_contact_info_url/"
}

These seem fine. And yes — we need to do a better job providing examples/defaults.

[jaeddy]

Might want to wait to see what happens with #119 and discussions with Discovery WS re: service-info spec before moving ahead with any WES-specific changes. cc @briandoconnor