mirror of
https://github.com/fnproject/fn.git
synced 2022-10-28 21:29:17 +03:00
e67d0e5f3f
In pure-runner and LB agent, service providers might want to set specific driver options. For example, to add cpu-shares to functions, LB can add the information as extensions to the Call and pass this via gRPC to runners. Runners then pick these extensions from gRPC call and pass it to driver. Using a custom driver implementation, pure-runners can process these extensions to modify docker.CreateContainerOptions. To achieve this, LB agents can now be configured using a call overrider. Pure-runners can be configured using a custom docker driver. RunnerCall and Call interfaces both expose call extensions. An example to demonstrate this is implemented in test/fn-system-tests/system_test.go which registers a call overrider for LB agent as well as a simple custom docker driver. In this example, LB agent adds a key-value to extensions and runners add this key-value as an environment variable to the container.
72 lines
1.6 KiB
Protocol Buffer
72 lines
1.6 KiB
Protocol Buffer
syntax = "proto3";
|
|
|
|
import "google/protobuf/empty.proto";
|
|
|
|
// Request to allocate a slot for a call
|
|
message TryCall {
|
|
string models_call_json = 1;
|
|
string slot_hash_id = 2;
|
|
map<string,string> extensions = 3;
|
|
}
|
|
|
|
// Data sent C2S and S2C - as soon as the runner sees the first of these it
|
|
// will start running. If empty content, there must be one of these with eof.
|
|
// The runner will send these for the body of the response, AFTER it has sent
|
|
// a CallEnding message.
|
|
message DataFrame {
|
|
bytes data = 1;
|
|
bool eof = 2;
|
|
}
|
|
|
|
message HttpHeader {
|
|
string key = 1;
|
|
string value = 2;
|
|
}
|
|
|
|
message HttpRespMeta {
|
|
int32 status_code = 1;
|
|
repeated HttpHeader headers = 2;
|
|
}
|
|
|
|
// Call has started to finish - data might not be here yet and it will be sent
|
|
// as DataFrames.
|
|
message CallResultStart {
|
|
oneof meta {
|
|
HttpRespMeta http = 100;
|
|
}
|
|
}
|
|
|
|
// Call has really finished, it might have completed or crashed
|
|
message CallFinished {
|
|
bool success = 1;
|
|
string details = 2;
|
|
int32 errorCode = 3;
|
|
string errorStr = 4;
|
|
}
|
|
|
|
message ClientMsg {
|
|
oneof body {
|
|
TryCall try = 1;
|
|
DataFrame data = 2;
|
|
}
|
|
}
|
|
|
|
message RunnerMsg {
|
|
oneof body {
|
|
CallResultStart result_start = 1;
|
|
DataFrame data = 2;
|
|
CallFinished finished = 3;
|
|
}
|
|
}
|
|
|
|
message RunnerStatus {
|
|
int32 active = 2; // Number of currently inflight responses
|
|
}
|
|
|
|
service RunnerProtocol {
|
|
rpc Engage (stream ClientMsg) returns (stream RunnerMsg);
|
|
|
|
// Rather than rely on Prometheus for this, expose status that's specific to the runner lifecycle through this.
|
|
rpc Status(google.protobuf.Empty) returns (RunnerStatus);
|
|
}
|