Setup FOCA boilerplate

[uniqueg]

Add tesk/config.yaml, following the basic structure of other FOCA apps, e.g., proTES and Cloud Registry.

For the OpenAPI specification, make sure to include the latest TES release 1.1 (commit 117cd92; direct link to specification corresponding to the tagged commit).

Note: The changes from TES 1.0 to 1.1 are not very substantial. Given that the majority of code changes required for the 1.1 upgrade are likely required in the API and the API code needs to be re-implemented anyway, it makes sense to develop against version 1.1 right away.

[JaeAeich]

add tesk/config.yaml, following the basic structure of other FOCA apps

So what will the structure look like, I thought initially api code will be in a separate dir, ie tesk/api. Let me know what makes sense here.

Str 1

Create a separation with api inside tesk

.
.
├── tesk
│   ├── api
│   │   ├── specs
|   │   │      ├── task_execution_service.openapi.yaml (exact copy of commit 117)
│   │   ├── app.py
│   │   ├── config.yaml
│   │   └── __init__.py
│   ├── __init__.py
│   └── services/
.
.

Str 2

Put all files in tesk.

.
.
├── tesk
│   ├── api
│   │   ├── task_execution_service.openapi.yaml (exact copy of commit 117)
│   ├── app.py
│   ├── config.yaml
│   ├── __init__.py
│   └── services/
.
.

[uniqueg]

Maybe like this?

.
├── tesk
│   ├── api
│   │   ├── ga4gh
|   │   │   ├── tes
|   │   │   |   ├── controllers.py  # or server.py, or whatever; could also consider putting the basic controller code in __init__.py, to save one level of nesting (can still use a subpackage for implementing non-trivial controllers)
│   │   |   |   └── __init__.py
│   │   |   └── __init__.py
│   │   ├── specs
|   │   │   └── task_execution_service.openapi.yaml (exact copy of commit 117)
│   │   └── __init__.py
│   ├── app.py
│   ├── __init__.py
│   └── services/

In this way, if TESK ever adopts other APIs, from GA4GH or otherwise, we will have a nice separation. Not that this is planned, but I wouldn't completely rule it out either.

As briefly mentioned previously, config.yaml I would put in the root or /deployment directory, because it's really just an example config for the app for quick starts that admins would/should modify for their particular circumstances.