This MR aims to replace !1115

Background

Theia has parameters embedded-sr, embedded-sr-type and embedded-instance-parameters that can be used to supply an SR and request an instance inside Theia from the panel / command-line request script. These options were added by !913 (merged) and !987 (merged).

The original rationale for these as I understood it was to bootstrap an embedded instance inside Theia without needing to first wait for the Theia to be allocated. That way, Theias with a ready embedded SR/instance could be automatically requested and be ready to use the next day, e.g. for a lesson on slapos using html5as SR.

Later, in !1105 (merged), the way this embedded instance is supplied and requested was changed to use a shell script that could later be edited and called manually by the user. This was to make the use case outlined above even easier: first, pre-supply/request an embedded instance, then let the user modify the buildout and change the parameters and supply/request it again, using the same mechanism so we know it works.

What this MR is about:

1. When the embedded sr/instance parameters in panel were changed, it would restart the standalone service, which would in turn cause all embedded instances to be stopped and then restarted. This MR fixes this.

2. The situation above actually outlines a larger issue: there are two competing use-cases for the embedded sr/instance parameters. In the first (original) case, they are meant for bootstrapping and the user will want to later manage the embedded instance in the Theia terminal, diverging from the original parameters. In the second use-case, the user wants to manage the embedded instance from the panel and expects the instance to converge to the parameters provided no matter what.

In !1115 I tried to accommodate both use-cases, using a toggle parameter to switch between behaviors. This proved both complicated and fragile in implementation, and non-intuitive and ambiguous in use.

Proposed changes (EDITED):

This section has been edited to reflect the latest version of this MR.

Options embedded-sr, embedded-sr-type and embedded-instance-parameters have been removed.

Instead, one-time-embedded-instance is introduced. This option is only only taken into account the first time when theia is instantiated, even if theia is instantiated with the default (empty) value. The goal is to allow the user to request a Theia with a preconfigured embedded instance, but not to let the user manage this instance from the panel.

The expected value for one-time-embedded-instance is a JSON object specifying the desired embedded instance:

• software-url: string of the software URL. This key is required.
• software-type: string of the software type. This key is optional.
• instance-parameters: JSON object of the parameter dict. This key is optional.

If a value is provided for the option, Theia's standalone service will attempt once to:

• Extract software-url, software-type and software-type from the JSON
• Create a supply/request script at ~/srv/project/request-embedded-instance.sh
• Run the script

If any of this fails, the error is logged as part of the standalone service logs and then ignored, and standalone service continues as normal. If it succeeds, the return code from the script is written to a dedicated file. Independently, a promise is created to check that Theia successfully managed to run the script by checking the existence and contents of the return code file.

If the promise fails forever, e.g. because the JSON is ill-formed or the SR fails to build, emptying the value in one-time-embedded-instance option will remove the promise. Editing the option with a fixed JSON will have no effect, even if the promise never succeeded. The only recourse for a failed preconfiguration is to use the command line in a Theia terminal. In the future we can hope there will be GUI inside Theia.

The supply/request script at ~/srv/project/request-embedded-instance.sh is created for the convenience of the user. It can be modified an re-run freely to update the embedded instance.

What else?

• I refactored slapos.recipe.template and slapos.recipe.template:jinja2 sections to use the new unified parameters introduced in version 5.0.
• Along the way, I refactored some tests as well.