Skip to content
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

43 api handle semantic failures in requests #54

Merged
merged 6 commits into from
Sep 28, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 49 additions & 0 deletions edgeless_api/proto/messages.proto
Original file line number Diff line number Diff line change
Expand Up @@ -53,6 +53,16 @@ message SpawnFunctionRequest {
StateSpecification state_specification = 6;
}

// Message to request the creation a new function instance.
message SpawnFunctionResponse {
// If present it means that the request has been rejected.
// In this case, other fields may not be present or contain meaningful data.
optional ResponseError response_error = 1;

// The identifier of the newly-spawned function instance, if accepted.
optional InstanceId instance_id = 2;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be a variant (similar to a Rust result) as one never gets both an error and an id.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean a oneof?

I am not particularly fond of that in protobuf because the C++ implementation of that is really stupid and dangerous.

Never used in Rust, we can try. Anyway, it will not guarantee that on-wire there is always at most, just that if there are two, the last one will be considered (which IMO is far less than ideal).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Fundamentally it should be clear that there should only be one of them. Since we use Rust as the main language (and in fact the Rust API is the reference while gRPC is just one binding) I would still model that using variants (although I'm not familiar with the C++ behavior).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, will do that as part of the API update following the 1st hackathon

(just FYI: in C++ the binding does not offer any special guarantee, it just leads to undefined behaviour if you do something like set(A), set(B), use(A) with A,B being in a oneof relation).

}

// Message to request the update of a function instance.
message UpdateFunctionLinksRequest {
// The function instance identifier.
Expand Down Expand Up @@ -97,6 +107,16 @@ message SpawnWorkflowRequest {
map<string, string> workflow_annotations = 4;
}

// Response to a request to create a new workflow.
message SpawnWorkflowResponse {
// If present it means that the request has been rejected.
// In this case, other fields may not be present or contain meaningful data.
optional ResponseError response_error = 1;

// The status of the newly-created workflow, if request accepted.
optional WorkflowInstanceStatus workflow_status = 2;
}

// Function instance mapping.
message WorkflowFunctionMapping {
// Name of the function within the workflow.
Expand Down Expand Up @@ -176,3 +196,32 @@ message ResourceInstanceSpecification {
// Map between the callbacks and instances that will be called.
map<string, InstanceId> output_callback_definitions = 3;
}

// Response to a request to create a new resource.
message SpawnResourceResponse {
// If present it means that the request has been rejected.
// In this case, other fields may not be present or contain meaningful data.
optional ResponseError response_error = 1;

// The status of the newly-created resource, if request accepted.
optional InstanceId instance_id = 2;
}

// Message containing information provided as response to failed request.
// The fields are inspired from the "problem detail" responses:
//
// https://www.rfc-editor.org/rfc/rfc7807.txt
//
// Currently all the fields are human-readable, i.e., they are intended to
// be shown and processed by human operators. Further optional fields might be
// added in the future that contain binary representations of information
// intended for machine processing, instead.
message ResponseError {
// A short, human-readable summary of the problem type.
// It should not change from occurrence to occurrence of the error.
string summary = 1;

// A human-readable explanation specific to this occurrence of the problem.
optional string detail = 2;
}

14 changes: 7 additions & 7 deletions edgeless_api/proto/services.proto
Original file line number Diff line number Diff line change
Expand Up @@ -9,8 +9,8 @@ package edgeless_api;
service FunctionInstance {
// Start a new function instance.
// Input: request containing the description of the function to create.
// Output: the function instance identifier assigned
rpc Start (SpawnFunctionRequest) returns (InstanceId);
// Output: the function instance identifier assigned, if accepted.
rpc Start (SpawnFunctionRequest) returns (SpawnFunctionResponse);

// Stop a running function instance.
// Input: the identifier of the function instance to tear down.
Expand All @@ -28,14 +28,14 @@ service FunctionInstance {
service WorkflowInstance {
// Start a new workflow.
// Input: request containing the description of the workflow to create.
// Output: the status of workflow instance newly created.
rpc Start (SpawnWorkflowRequest) returns (WorkflowInstanceStatus);
// Output: the status of workflow instance newly created, if accepted.
rpc Start (SpawnWorkflowRequest) returns (SpawnWorkflowResponse);

// Stop an active workflow.
// Input: the identifier of the workflow to tear down.
// Output: none.

rpc Stop (WorkflowId) returns (google.protobuf.Empty);

// List the active workflows or shows the status of a given active workflow.
// Input: the identifier of the active workflow or a special value indicating all workflows.
// Output: the list of status of the active workflow instances.
Expand All @@ -54,8 +54,8 @@ service FunctionInvocation {
service ResourceConfiguration {
// Create a new resource.
// Input: specification of the resource to be created.
// Output: the identifier of the newly created resource.
rpc Start (ResourceInstanceSpecification) returns (InstanceId);
// Output: the identifier of the newly created resource, if accepted.
rpc Start (ResourceInstanceSpecification) returns (SpawnResourceResponse);

// Terminate an existing resource.
// Input: the identifier of the resource to be terminated.
Expand Down
5 changes: 5 additions & 0 deletions edgeless_api/src/common/mod.rs
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
#[derive(Clone, Debug)]
pub struct ResponseError {
pub summary: String,
pub detail: Option<String>,
}
19 changes: 18 additions & 1 deletion edgeless_api/src/function_instance/mod.rs
Original file line number Diff line number Diff line change
@@ -1,3 +1,5 @@
use crate::common::ResponseError;

// TODO(raphaelhetzel) These should be actual types in the future to allow for type-safety.
pub type NodeId = uuid::Uuid;
pub type NodeLocalComponentId = uuid::Uuid;
Expand Down Expand Up @@ -57,6 +59,21 @@ pub struct SpawnFunctionRequest {
pub state_specification: StateSpecification,
}

#[derive(Debug, Clone)]
pub struct SpawnFunctionResponse {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Especially the rust representation must be a result-like object.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I can agree to that (my idea was to keep the Rust structures close to the original gRPC data structures, but there is no need for this).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As suggested above, the Rust trait is the reference, the gRPC binding only one of possibly many bindings.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fine, will do that. I am not opening an issue for this, it will part of the upcoming API refactoring.

pub response_error: Option<ResponseError>,
pub instance_id: Option<InstanceId>,
}

impl SpawnFunctionResponse {
pub fn good(instance_id: crate::function_instance::InstanceId) -> Self {
Self {
response_error: None,
instance_id: Some(instance_id),
}
}
}

#[derive(Debug)]
pub struct UpdateFunctionLinksRequest {
pub instance_id: Option<InstanceId>,
Expand All @@ -65,7 +82,7 @@ pub struct UpdateFunctionLinksRequest {

#[async_trait::async_trait]
pub trait FunctionInstanceAPI: FunctionInstanceAPIClone + Sync + Send {
async fn start(&mut self, spawn_request: SpawnFunctionRequest) -> anyhow::Result<InstanceId>;
async fn start(&mut self, spawn_request: SpawnFunctionRequest) -> anyhow::Result<SpawnFunctionResponse>;
async fn stop(&mut self, id: InstanceId) -> anyhow::Result<()>;
async fn update_links(&mut self, update: UpdateFunctionLinksRequest) -> anyhow::Result<()>;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given this is mostly a start request this will need similar semantics.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean for the update_links()?

If yes, then I am not sure I can agree:

Starting a new instance is something that may need a lot of resources and might have constraints. There are many reasons why one should refuse (not enough memory available, cores overloaded, annotation specifies the need for a GPU but it is already used/locked by another process, ...).

The update_links does not require more resources because it is a mere update of a forwarding table, which should not fail unless exceptional circumstances happen (I don't know, not enough memory to add few bytes needed to the data structure?).

IMO, we should use fail-semantics for start-like methods, which may be rejected in non-exceptional circumstances, while we do not need to require fail-semantics for those that may only fail in exceptional cases.

Copy link
Collaborator

@raphaelhetzel raphaelhetzel Sep 30, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I mean update links. One can still think of some scenarios that might lead to a rejection (e.g. when violating some security policy by trying to link to some other namespace/workflow).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see two consistent ways of making things.

A. We implement the fail-semantics on 100% of the calls, e.g., read-only methods. That's fine, since something can always go wrong in life.

B. We implement the fail-semantics only on methods that may be willingly rejected.

I don't like A at this stage because things are moving and there will be maintenance cost to be paid.

If we go for B, as I recommend for now, then I think that update_links does not fall into the category of methods for which the node may reject that.

The violation of a security policy is something which has not been defined, as of today. When this will be a thing, then update_links will fall into the right category add we will add the fail-semantics accordingly.

I think it's more efficient to proceed on a "let's do only things that makes sense today" way and not to overdesign because our resources are very limited.

}
Expand Down
31 changes: 31 additions & 0 deletions edgeless_api/src/grpc_impl/common.rs
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
pub struct CommonConverters {}

impl CommonConverters {
pub fn parse_response_error(api_request: &crate::grpc_impl::api::ResponseError) -> anyhow::Result<crate::common::ResponseError> {
Ok(crate::common::ResponseError {
summary: api_request.summary.to_string(),
detail: api_request.detail.clone(),
})
}

pub fn parse_instance_id(api_id: &crate::grpc_impl::api::InstanceId) -> anyhow::Result<crate::function_instance::InstanceId> {
Ok(crate::function_instance::InstanceId {
node_id: uuid::Uuid::parse_str(&api_id.node_id)?,
function_id: uuid::Uuid::parse_str(&api_id.function_id)?,
})
}

pub fn serialize_response_error(crate_function: &crate::common::ResponseError) -> crate::grpc_impl::api::ResponseError {
crate::grpc_impl::api::ResponseError {
summary: crate_function.summary.clone(),
detail: crate_function.detail.clone(),
}
}

pub fn serialize_instance_id(instance_id: &crate::function_instance::InstanceId) -> crate::grpc_impl::api::InstanceId {
crate::grpc_impl::api::InstanceId {
node_id: instance_id.node_id.to_string(),
function_id: instance_id.function_id.to_string(),
}
}
}
Loading