Design Management API surface

The Management API should allow for control plane and eventually data plane operations to provision resources , list metadata about resources, update the state of resources etc.

The Management API will evolve as new concepts and features are introduced but we anticipate the core operations to manage workspaces and services to be part of the initial API version.

We envision a RESTful HTTP API along the lines of:

• GET /workspaces - Get workspaces
• POST /workspaces - Create workspace
• GET /workspaces/{workspace_id} - Get specific workspace
• DELETE /workspaces/{workspace_id} - Delete specific workspace
• GET /sharedservices - Get core (shared) services
• GET /sharedservices/{shared_service_id} - Get core (shared) service
• GET /workspaces/{workspace_id}/services - Get workspace services
• POST /workspaces/{workspace_id}/services - Create workspace service
• DELETE /workspaces/{workspace_id}/services - Delete workspace service
• GET /workspaces/{workspace_id}/services/{workspace_service_id}/resources - Create workspace service resources
• POST /workspaces/{workspace_id}/services/{workspace_service_id}/resources - Create a workspace service resource
• GET /workspaces/{workspace_id}/services/{workspace_service_id}/resources/{workspace_service_resource_id} - Get workspace service resource
• DELETE /workspaces/{workspace_id}/services/{workspace_service_id}/resources/{workspace_service_resource_id} - Get workspace service resource

Examples

These requests are very simplistic just to illustrate the conceptual journey of creating a workspace containing a Data Science Virtual Machine. Actual spec to be developed as part of closing this issue.

Create workspace

POST /workspaces
Content-Type: application/json

{
    "name": "Workspace One",
    "owner": "chris"
}

# this will probably have to be async with a 202 Accepted in reality
201 Created
Location: /workspaces/1

{
    "id": 1,
    "name": "Workspace One",
    "owner": "chris"
}

Create workspace service - Virtual Desktops with shared Firewall

POST /workspaces/1/services
Content-Type: application/json

{
    "service_type": "virtual_desktops",
    "firewall": "shared"
}

201 Created
Location: /workspaces/1/services/2

{
    "id": 2,
    "service_type": "virtual_desktops",
    "firewall": "shared"
}

Create workspace service resource - Linux DS VM

POST /workspaces/1/services/2/resources
Content-Type: application/json

{
    "name": "DS VM One",
    "size": "Standard_DS3_v2",
    "image": {
        "publisher": "microsoft-dsvm",
        "offer": "ubuntu-1804",
        "version": "latest"
}

201 Created
Location: /workspaces/1/services/2/resources/3

{
    "id": 3,
    "name": "DS VM One",
    "size": "Standard_DS3_v2",
    "image": {
        "publisher": "microsoft-dsvm",
        "offer": "ubuntu-1804",
        "version": "latest"
}

[jjcollinge]

A service can be anything defined by a terraform configuration. The workspace provides a virtual network for which the service can be deployed. We only have a definition for a DSVM service in our implementation which means we haven’t got a concrete design for ingress etc.

[christoferlof]

Thanks @jjcollinge . I fixed the formatting of the table, why the post says it was edited by me.