-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define a serverless protocol #1
Comments
CommandsConfigureRequestThis command would configure the agent with fields such as:
Note: it could be just one command with all the needed configuration. ResponseOn success, return OK (or a similar message). On error, return NOK (or similar), with a reason. RunThis command can be called once the configuration was successful. RequestStarts the code ResponseThis 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. LogsRequestA simple log from the guest to the host. They include:
ResponseInterruptions / StopRequestJust a signal to stop the guest ResponseNothing. Subjects to consider:
|
CommunicationSlip BasedAs for the communication, for now, I thought we could either use a SLIP Based protocol over the serial line. It would look like this:
The message type could be log, config, etc. ProtobufWe 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. |
@virt-do/vmm |
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. |
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. |
After experimenting with communication over serial ports, here's my two cents: Reminder:
CommunicationThe VMM and agent will exchange messages over the serial port until Virt-IO is ready to be implemented. To make sure each message is received, it should be request response based. Messages Typespub enum MessageType {
Start = 0,
Exit = 1,
Interrupt = 2,
Ok = 3,
Log = 4,
}
/// Expects OkMessage
/// Sent when the Agent starts
pub struct StartMessage {
content: String,
}
/// Expects OkMessage
/// Sent when the agent exits
pub struct ExitMessage {
code: i32,
content: String,
}
/// Expects OkMessage
/// Sent when the VMM wants to stop the agent
pub struct InterruptMessage {
signal: i32,
}
/// Mostly used to answer other messages
pub struct OkMessage {}
/// Expects OkMessage
pub struct LogMessage {
kind: String,
content: String,
} ATM I'm unsure of whether the LogMessage is useful since the program could simply send them to stdout, I'd like to have your input. Message Format
We should go for this format, which would be easier to implement. It's the easiest format to make evolve. The Message Type would identify what to serialize the data into: pub enum MessageType {
A = 0,
B = 1,
...
} For example, if the receiver gets a message type of 1, we would serialize the message in the The checksum is simply here to make sure we didn't miss any data. We just need to determine what algorithm to use and the size of the checksum. Please give me your input and whether you think we could implement that. @virt-do/vmm @virt-do/guest-agent |
Also, I forgot to mention that we should have a terminator to determine when the message is done. Here's an idea:
|
I have questions, only for the definition, not code related:
I also think we should consider the protobuf de/serialization and/or grpc protocol over the slip, maybe it could be easier, but I wonder if it adds too much overhead (since it's using http) and if it's possible over serial |
Again, if you manage to make a proof of concept, I'd love to do it. For information, here's a POC of what I described: https://github.com/mmoreiradj/serial-port-demo |
A protocol for the host (Lumper) to send commands to the guest (serverless agent #6) and receive replies from it.
The text was updated successfully, but these errors were encountered: