Create Review VM from the Airlock UI screen

[tanya-borisova]

Description

As a TRE Airlock Manager
I want to have a button next to the Airlock Request to spin up the Review VM
So that I don't have to remember which workspace and workspace service to create it in and I don't have to copy SAS URL

Implementation proposal

Configuration

We propose to add an additional nested block to Research Workspace (=base workspace) properties for configuring the Airlock Review VMs.

This could look like this:

{
    "id": "<id>",
    "templateName": "tre-workspace-base",
    "templateVersion": "0.3.28",
    "properties": {
        "enable_airlock": true,
        "airlock_review_config": {
            "import": {
                "workspace_id": "<guid>",  // ID for the already deployed Import Review Workspace to use for reviews
                "workspace_service_id": "<guid>",  // ID for the already deployed Workspace Service to deploy review VMs to
                "user_resource_template_name": "guacamole-azure-import-reviewvm"  // the user resource template to create
            },
            "export": {
                "workspace_serivce_id": "<guid>",  // ID for the already deployed Workspace Service to deploy review VMs to
                "user_resource_template_name": "guacamole-azure-import-reviewvm"  // the user resource template to create
            },
        },
    // other properties as normal
    },

The export section does not have workspace_id because for export it will always be the Research Workspace the data is exported from.
The corresponding resources need to already be deployed before this configuration can be set, which is why we should recommend users to issue an update on an existing resource if they wish to configure Airlock Review.

UI screens

We then propose to add a button / screen on the UI next to the Airlock Review requests (updated in Figma):

The button will be greyed out if the above configuration is not set for the workspace, with a message for the user to ask their TRE admin to configure this for them.

If there already is a review VM created for the request by this user, it could show a link to that created review VM.
If the review VM was created by another user, it could show a message saying that another user is currently reviewing this request. For this, the review_user_resources field in Airlock Request object is used (see below).

API endpoint

Add a corresponding API endpoint that will create a review User Resource

/api/workspaces/{workspace_id}/requests/{airlock_request_id}/create-review-user-resource

This will accept the Research Workspace ID and Request ID as parameters, from the properties outlined above will determine in which Workspace and Workspace Service to create them in, will create the user resource and return the Operation to watch, which will be tracked in the usual way on the UI.

The API endpoint will also update the Request object with the information on this VM:

{
    "id": "45e1d9d8-f669-47bf-b0eb-a11bb34aa456",
    "workspaceId": "26f41c2a-2bed-4f78-a745-c41ca8f326fe",
    "requestType": "export",
    "files": [
        {
            "name": "research_result.txt",
            "size": 7
        }
    ],
    "review_user_resources": [
        {
            "id": "<guid>",
            "workspace_id": "<guid>",
            "workspace_service_id": "<guid>"
        }
    ],
    // other properties as normal
}

Acceptance criteria

• Base workspace properties are updated with Airlock Review configuration #2736
• API endpoint is added for creating Review user resources #2737
• UI for Airlock Review VM #2738
• Review VM configuration should not be visible when creating workspace #2830

[marrobi]

Feels like a nice idea.

Question on how this displays in the create/update workspace UI? Are these fields required? Only if airlock is enabled? I won't know the workspace service ID when creating the workspace. Can we have a think through the user flow for configuration?

[tanya-borisova]

@marrobi

Question on how this displays in the create/update workspace UI? Are these fields required? Only if airlock is enabled? I won't know the workspace service ID when creating the workspace. Can we have a think through the user flow for configuration?

The idea was that the workspace is created without these fields, and they are not required: as you said, we can't provide the IDs yet when creating the workspace.

The flow would be this:

• TRE Admin deploys a Research Workspace with Airlock enabled, and a Guacamole inside that workspace
• TRE Admin deploys a separate Import Review workspace, and a Guacamole inside that workspace
• When they have all that, they issue a PATCH request to the Research Workspace with this information:

{
  "properties": {
    "airlock_review_config": {
      "import": {
        "workspace_id": "1c79...23f71",
        "workspace_service_id": "0e4...745",
        "user_resource_template_name": "guacamole-azure-import-reviewvm"
      },
      "export": {
        "workspace_service_id": "ca8...d64",
        "user_resource_template_name": "guacamole-azure-export-reviewvm"
      }
    }
  }
}

(We will document all this, of course!)

[tanya-borisova]

I think this won't be available on the create / update workspace UI, as these will be in property bag, but we could think to add it there? @jjgriff93 @damoodamoo

[marrobi]

Could they be hidden on create and visible on update/patch?

If they aren't set then the create review vm would not be visible?

Need to make sure they are validated on patch to be valid Ids.

[tanya-borisova]

Could they be hidden on create and visible on update/patch?

Potentially? May need to add a new field type for that though (similar to updateable that we already have)

If they aren't set then the create review vm would not be visible?

Yes, that's the idea.

Need to make sure they are validated on patch to be valid Ids.

Hmm yeah I think that's doable, we can add that logic either in API or even on the UI, when the user inputs these fields

[damoodamoo]

I would imagine that they'll be present in the UI - we currently don't have a way to hide things for create but show only for update. We could do that down the line - but in the near term we would just add some description on the fields to let the user know they're optional and can be updated later.

Would be reticent to add special code to validate that the IDs are correct - I think we could add a regex in the template to make sure it's a guid, but not that it relates to a valid resource. That's up to the TRE admin to get right, and if it's not right then the error coming back from a review VM creation would tell them about it.

[jjgriff93]

Added proposed UI designs