🔱 Track Tool deployments within Control Panel

[michaeljcollinsuk]

Context

For every tool release created via Control Panel, a database record is created. However there is no record in the DB that links a deployed tool release to users. To figure out which tool release a user is using, we use the Kubectl API to:

1. Get all deployments for a users namespace
2. Filter those deployments for the each tool (rstudio, vscode, jupyter)
3. Extract the relevant container for each of the deployments
4. Parse the image tag from the container metadata
5. Use this to try to match it to a release in the Control Panel database

This results in a lot of heavy API calls and brittle code in order to get what is used as simple display information. There is no easy way to query how many users are using each release, which in turn makes it difficult to deprecate tools and get users to upgrade.

The amount of custom code required also makes it difficult to change and susceptible to bugs - currently there is an issue where sometimes the wrong tool is displayed as "installed" which is a direct result of the above.

Proposal

Update the Control Panel models to add a many-to-many between Tools and Users, with a through table where we can store additional information (such as timestamps, and the chart_name to allow us to use a unique_together restriction ). In practice this will mean that when a user selects a tool, and clicks deploy, we will create a database record of the tool that they have deployed. If they select a different tool, we then update this object to point to the newly deployed release.

All tool options displayed to users will read directly from the database, removing the need for using Kubernetes/Helm api's to find options for tools to release. We can also simplify the logic used when deploying a tool, as we can simply lookup the database object and extract all the relevant information from it to deploy the new release.

Overall this will reduce the amount of code and make the logic much more simple to follow for developers. It will also allow us to easily query the number of users that are using each release of a tool.

CONSIDERATIONS

• We will either need a data migration to create initial records of each tool a user has deployed, or treat this as a "reset" moment. This would mean that users lose the record of which tool they currently have installed, and will need to select one to deploy as if they have not previously deployed one on their first login.

Spike requirements

Developer, 5 days

Definition of Done

• Models have been updated
• Consider data migration
• Consider "reset"
• Frontend updated to read from DB
• Forms updated to store records of deployed tools for a user
• Test in dev environment