search

ga4gh / workflow-execution-service-schemas

The WES API is a standard way to run and manage portable workflows.
Apache License 2.0
82 stars 38 forks source link

Clean up `service-info` based on AMED feedback #125

Open jaeddy opened 5 years ago

jaeddy commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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