Implement GetCapabilities endpoint in OpenAPI spec

[vsmalladi]

Added capabilities endpoint to retrieve TES backend features. Closes #206
Closes #188

[vsmalladi]

Response would be like this

{
  "cpu_cores": 32,
  "ram_gb": 256,
  "disk_gb": 2000,
  "num_machines": 8,
  "accelerators": [
    {
      "type": "GPU",
      "count": 4
    },
    {
      "type": "TPU",
      "count": 2
    }
  ],
  "chip_type": "x86_64",
  "fpga": true
}

[vsmalladi]

Add docker or other container resources.

[andrew-nimbus]

I also wonder if we want to focus an initial version of the capability on providing GPU metadata (in addition to some baseline CPU/disk/mem inventory as well)--one would probably want things like the vendor, model, GPU mem per device, driver type and version, GPU execution model (e.g., exclusive vs. partitioned), runtime version, and the types of containers supported (which you note in the comment--indicating singularity support would likely be esp useful)--right? I'm trying to think about how irritating it can be to match a container to an accelerator environment.

Along these lines, do we want to expand the GPU metadata (to potentially target an eventual PoC implementation) and drop the FPGA flag for the moment (as it's unclear to me how to use this boolean in practice...but ive never used FPGA accelerators before).

[andrew-nimbus]

On another note, we'll want to make clear in the updated documentation that the initial goal here is to facilitate helping jobs to run on the hardware (esp. accelerators)--scheduling and optimization are for later.

I.e., this is a static inventory (i.e., "is there a GPU accessible to the TES endpoint") but not focused on status (e.g., "is the GPU available now?"). Is the implicit assumption that the TES server is effectively managing current state via its set of workers at the moment? I think this is perfectly reasonable, but it would be worth being explicit about it in any updated documentation.

[uniqueg]

I'm all for this, but would prefer for this to be hosted at /service-info (as a product-specific extension of the Service Info API), so that it becomes discoverable through the GA4GH Service Registry API.

Also, perhaps we should think of a more generic/extensible format to encourage plugin development by the community.

Finally, I think we should consider coordinating this with other GA4GH products within the Cloud WS, or across the Cloud and Discovery WS (which together govern all, or almost all, of GA4GH's OpenAPI products).

A possible approach and example use cases are outlined in ga4gh/TASC#45.