Populate the Base workspace object with template information at creation time, to hold version data

[TonyWildish-BH]

The Base workspace template is defined by a JSON object. This needs to be extended to hold information about all the workspace services and their user resources, specifically to list which versions are available to the workspace.

Something like this, though the details are up for grabs:

{
  "Guacamole": {
      "versions": [
        { "1.0.0": False },
        { "1.2.0": True },
        { "2.0.0": False },
      ],
      "user-resources": {
        "Guacamole Linux VM": {
            "versions": [
              { "2.0.2": True },
              { "2.1.0": True }
            ]
        },
        "Guacamole Windows VM": {
        }
    }
  ...
}

The essential points are:

• have the list of workspace services
• for each service, list the versions
• for each service, list the child resources (user-resources) recursively

For child resources, there are no sub-children, so the structure could be simplified by not having the "versions" key, and lifting the list of versions up a level.

The "versions" sub-structure should have entries in order. String-sorting may not work, since the version number has MAJOR.MINOR.PATCH structure.

The information to fill this structure comes from the list of registered templates in CosmosDB.

[TonyWildish-BH]

N.B., eventually, we will need two boolean flags per version, one for the TRE Admin and one for the Workspace Admin. The Workspace Admin will be able to change their flag only if the TRE Admin has enabled that version for a workspace (see the Service Catalogue slide deck we discussed recently).

This suggests that the version array should look something like this, instead:

      "versions": [
        { "1.0.0": [ False, False ] },
        { "1.2.0": [ True, True ] },
        { "2.0.0": [ True, False ] },
      ],

where, for example, the TRE Admin manipulates the first element, and the Workspace Admin manipulates the second element. So in this example, version 1.0.0 is disabled, and only the TRE Admin can enable it. Version 1.2.0 is enabled, and either role can enable/disable it. Version 2.0.0 is allowed by the TRE Admin, but the Workspace Admin has not enabled it for their project.

[TonyWildish-BH]

To clarify from the Show & Tell, I envision this object being built in the workspace CosmosDB entry when the workspace is created, by trawling the list of ResourceTemplates that are available from CosmosDB.

The object should be updated (refreshed) with new versions when the TRE Admin goes into the Configuration tab to configure the set of versions available for each workspace. That's covered in #191, and doesn't need to be done yet.

The workflow we discussed, as I understand it, and I'm happy to be corrected, would look like this:

• Monday: TRE Admin creates Workspace_A. Versions object in workspace object is populated with existing resource templates at that time. So, for example, this includes AzureML version 1.0.0.
• Tuesday: TRE Admin creates new version of a template, e.g. AzureML template version 2.0.0. No workspace objects are updated at this point.
• Wednesday: Workspace_A Admin comes along and deploys AzureML. They only have version 1.0.0 available to them.
• Thursday: TRE Admin goes into Workspace_A and opens the Configuration tab. At that point, the ResourceTemplate list is scanned again, and is merged into the workspace. AzureML 2.0.0 then shows up, disabled by default. The TRE Admin can enable it, and save the configuration.
• Friday: Workspace_A Admin comes along and deploys another AzureML (maybe they now have two, maybe they deleted the first one, no matter). This time, they get version 2.0.0 by default (latest active version in their workspace).

Future enhancements will allow them to choose between version 1.0.0 and 2.0.0 if both are still enabled, but for now, it's enough to deploy the latest active version.

Another possible enhancement is for when we start to allow the Workspace Admin to control versions themselves, and that's to do the object refresh when the Workspace Admin goes into the Configuration tab. That's out of scope for this epic, we're only working with the TRE Admin access.

[E-PAC]

MR
https://github.com/Barts-Life-Science/AzureTRE/pull/new/feature/template_version_number_misc

USAGE

1. run script
2. create object in cosmosDB
3. edit object with script output