Define a serverless protocol

[sameo]

A protocol for the host (Lumper) to send commands to the guest (serverless agent #6) and receive replies from it.

• Define commands and responses
• Define packet format

[mmoreiradj]

Commands

Configure

Request

This command would configure the agent with fields such as:

• language
• variables/inputs
• code
• log level

Note: it could be just one command with all the needed configuration.

Response

On success, return OK (or a similar message).

On error, return NOK (or similar), with a reason.

Run

This command can be called once the configuration was successful.

Request

Starts the code

Response

This command would start a build (if needed) and the run code.

It would return nothing on successful reception of the command, but it would log the steps it takes.

Logs

Request

A simple log from the guest to the host.

They include:

• Error: runtime errors, build error, configuration errors
• Info: code result, maybe compiler warnings
• Debug: steps taken, building time, starting time, etc.

Response

Interruptions / Stop

Request

Just a signal to stop the guest

Response

Nothing.

Subjects to consider:

• Do we need an interruption command ?
• Metrics ? Can't the VMM get those without the agent communicating them ?
• Timeouts ? Retries ?
• Multiple Files ? Since we've separated the configuration and runtime, this could be a possibility.

[mmoreiradj]

Communication

Slip Based

As for the communication, for now, I thought we could either use a SLIP Based protocol over the serial line. It would look like this:

Information	Length (in bits)
Message Type	16
Checksum	16
Data	...

The message type could be log, config, etc.

Protobuf

We could also define .proto file and serialize / deserialize the messages with it.

Note that this could be reused if we manage to set up virtio-net and use gRPC further down the line.

[mfernd]

@virt-do/vmm

[charley-geoffroy]

Hello @mmoreiradj and thanks for your job !

Every thing looks good to me !

Regarding the interruption command, I agree that it would be beneficial to have such a feature. It would allow for the proper termination of code execution, which can be more efficient in terms of resource management compared to letting a code run that will inevitably need to be restarted.

As for metrics, it indeed depends on the available time, but having feedback such as execution time and memory usage could be valuable. These metrics could provide insights into the performance and efficiency of the code, which can be useful for optimization purposes.

Concerning multiple files, it still depends on the available time, one potential use case could be when a user's code is divided into several modules or when the codebase is large ?? But is this really useful for the moment ?

Regarding the communication part, I would suggest using Protobuf for its efficient serialization and deserialization capabilities, as well as its strict and maintainable nature and also as you said, it could be reused if we manage to get virtio up and running-net and use gRPC further.

[charley-geoffroy]

Also, Muriel, would suggest that the "run" command should return the container ID, which should be used for all other commands (such as metrics, shutdown, etc.).

[mfernd]

Also, Muriel, would suggest that the "run" command should return the container ID, which should be used for all other commands (such as metrics, shutdown, etc.).

We (agent) needs to run only one process, so I don't think it's useful to return an id for this.