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

Cloud API: Nexus Incoming/Outgoing Service Definitions #16

Closed
wants to merge 23 commits into from
Closed
Show file tree
Hide file tree
Changes from 2 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
87 changes: 87 additions & 0 deletions temporal/api/cloud/cloudservice/v1/request_response.proto
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,7 @@ option go_package = "go.temporal.io/api/cloud/cloudservice/v1;cloudservice";
import "temporal/api/cloud/operation/v1/message.proto";
import "temporal/api/cloud/identity/v1/message.proto";
import "temporal/api/cloud/namespace/v1/message.proto";
import "temporal/api/cloud/nexus/v1/message.proto";
import "temporal/api/cloud/region/v1/message.proto";

message GetUsersRequest {
Expand Down Expand Up @@ -229,3 +230,89 @@ message GetRegionResponse {
// The temporal cloud region.
temporal.api.cloud.region.v1.Region region = 1;
}

message GetIncomingServicesRequest {
Copy link
Member

Choose a reason for hiding this comment

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

Wonder why not call this "list" instead of "get", I find this confusing but I figure it's consistent with other cloud APIs.

Copy link
Member

Choose a reason for hiding this comment

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

Please mention if these are AND or OR filters in the comment for this message.

Copy link
Member Author

Choose a reason for hiding this comment

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

yeah the list vs get is for consistency with existing cloud apis. could have been list.

these are AND filters. will update comments

// The requested size of the page to retrieve - optional.
// Cannot exceed 1000. Defaults to 100.
int32 page_size = 1;

// The page token if this is continuing from another response - optional.
string page_token = 2;

// Filter incoming services by the namespace they route to - optional.
string namespace = 3;

// Filter incoming services by the task queue they route to - optional.
Copy link
Member

Choose a reason for hiding this comment

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

nit: Do we really need to support filtering with task_queue? Can't think of a usecase.

Copy link
Member Author

Choose a reason for hiding this comment

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

My thought was that we might multiple services across different environments (test, stage, dev, prod) where the task queue is the same, but the namespace varies. @bergundy @prasek if this makes sense or not

Copy link
Member Author

Choose a reason for hiding this comment

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

spoke offline, we think this is useful to have this filter here

string task_queue = 4;
}

message GetIncomingServicesResponse {
// The list of incoming services in ascending ids order
mastermanu marked this conversation as resolved.
Show resolved Hide resolved
repeated temporal.api.cloud.nexus.v1.IncomingService incoming_services = 1;

// The next page's token
string next_page_token = 2;
}

message GetIncomingServiceRequest {
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
message GetIncomingServiceRequest {
message GetIncomingServiceByIdRequest {

Just in case we want to add a "by name" request?
The list approach is also fine, just a bit harder to use IMHO.

Copy link
Member

Choose a reason for hiding this comment

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

Can it simply be 'GetIncomingServiceRequest' and if/when we add by name, we'd add 'GetIncomingServiceByNameRequest'? Or is this against a convention for the 'ById' suffix we already use? I see that in

we named a similar message 'GetUserRequest' even though it takes a user 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.

agreeing with sergey here. am inclined towards leaving this as is for now (e.g. GetIncomingServiceRequest) just to be consistent with existing cloud user apis

the weirdness is that when we translate this to HTTP path, we would end up creating a different path at that time probably, but not the end of the world if we have to introduce that

// The id of the incoming service to get
string incoming_service_id = 1;
Copy link
Member

Choose a reason for hiding this comment

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

nit: can we just call this id? it's already in the context of an GetIncomingServiceRequest.

Copy link
Member Author

@mastermanu mastermanu Mar 13, 2024

Choose a reason for hiding this comment

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

we can. I was trying to be consistent with this one: https://github.com/temporalio/api-cloud/blob/main/temporal/api/cloud/cloudservice/v1/request_response.proto#L33 but I definitely wish that used id

will leave as-is for now unless there is strong feeling about it

}

message GetIncomingServiceResponse {
// The incoming service
temporal.api.cloud.nexus.v1.IncomingService incoming_service = 1;
}

message CreateIncomingServiceRequest {
// The spec for the incoming service
temporal.api.cloud.nexus.v1.IncomingServiceSpec spec = 1;

// The id to use for this async operation - optional
string async_operation_id = 2;
}

message CreateIncomingServiceResponse {
// The id of the service that was created
string incoming_service_id = 1;

// The async operation
temporal.api.cloud.operation.v1.AsyncOperation async_operation = 2;
}

message UpdateIncomingServiceRequest {
// The id of the incoming service to update
string incoming_service_id = 1;

// The updated incoming service specification
temporal.api.cloud.nexus.v1.IncomingServiceSpec spec = 2;

// The version of the incoming service for which this update is intended for
// The latest version can be found in the GetIncomingService operation response
string resource_version = 3;

// The id to use for this async operation - optional
string async_operation_id = 4;
}

message UpdateIncomingServiceResponse {
// The async operation
temporal.api.cloud.operation.v1.AsyncOperation async_operation = 1;
}

message DeleteIncomingServiceRequest {
// The id of the incoming service to delete
string incoming_service_id = 1;

// The version of the incoming service for which this delete is intended for
// The latest version can be found in the GetIncomingService operation response
string resource_version = 2;

// The id to use for this async operation - optional
string async_operation_id = 3;
}

message DeleteIncomingServiceResponse {
// The async operation
temporal.api.cloud.operation.v1.AsyncOperation async_operation = 1;
}
37 changes: 37 additions & 0 deletions temporal/api/cloud/cloudservice/v1/service.proto
Original file line number Diff line number Diff line change
Expand Up @@ -118,4 +118,41 @@ service CloudService {
get: "/api/v1/regions/{region}",
};
}

// Gets all known nexus incoming services
rpc GetIncomingServices(GetIncomingServicesRequest) returns (GetIncomingServicesResponse) {
option (google.api.http) = {
get: "/api/v1/nexus/incomingservices",
mastermanu marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Member

Choose a reason for hiding this comment

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

Can we add a /by-id or /id suffix to this URL just in case we want to allow looking up by name eventually?

Copy link
Member Author

Choose a reason for hiding this comment

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

since I am following what we do for users, I've kept the same format (which doesn't have by-id or id either..). @anekkanti , thoughts?

Copy link
Member

Choose a reason for hiding this comment

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

I think for the default behavior (by ID) we don't need to add a suffix.

Copy link
Member Author

Choose a reason for hiding this comment

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

yes, am inclined to leave as-is as well. can always add suffix later if needed

};
}

// Get an incoming service
rpc GetIncomingService(GetIncomingServiceRequest) returns (GetIncomingServiceResponse) {
option (google.api.http) = {
get: "/api/v1/nexus/incomingservices/{incoming_service_id}",
};
}

// Create an incoming service
rpc CreateIncomingService(CreateIncomingServiceRequest) returns (CreateIncomingServiceResponse) {
option (google.api.http) = {
post: "/api/v1/nexus/incomingservices",
body: "*"
};
}

// Update an incoming service
rpc UpdateIncomingService(UpdateIncomingServiceRequest) returns (UpdateIncomingServiceResponse) {
option (google.api.http) = {
post: "/api/v1/nexus/incomingservices/{incoming_service_id}",
body: "*"
};
}

// Delete an incoming service
rpc DeleteIncomingService(DeleteIncomingServiceRequest) returns (DeleteIncomingServiceResponse) {
option (google.api.http) = {
delete: "/api/v1/nexus/incomingservices/{incoming_service_id}",
};
}
}
46 changes: 46 additions & 0 deletions temporal/api/cloud/nexus/v1/message.proto
Original file line number Diff line number Diff line change
@@ -0,0 +1,46 @@
syntax = "proto3";

package temporal.api.cloud.nexus.v1;

option go_package = "go.temporal.io/api/cloud/nexus/v1;nexus";

import "google/protobuf/timestamp.proto";

message IncomingServiceSpec {
// The name of the incoming service. Must be unique within an account
mastermanu marked this conversation as resolved.
Show resolved Hide resolved
// The name must match `[a-zA-Z_][a-zA-Z0-9_]*`.
string name = 1;

// The namespace to route requests to
mastermanu marked this conversation as resolved.
Show resolved Hide resolved
string namespace = 2;

// The task queue to route requests to
string task_queue = 3;
}

// A binding from a service name to namespace and task queue for dispatching incoming Nexus requests.
message IncomingService {
mastermanu marked this conversation as resolved.
Show resolved Hide resolved
// The id of the service. This is generated by the server and is immutable
string id = 1;
mastermanu marked this conversation as resolved.
Show resolved Hide resolved

// The current version of the incoming service specification
// The next update operation must include this version
string resource_version = 2;
mastermanu marked this conversation as resolved.
Show resolved Hide resolved

// The incoming service specification
IncomingServiceSpec spec = 3;

// The current state of the service
mastermanu marked this conversation as resolved.
Show resolved Hide resolved
string state = 4;

// The id of the async operation that is creating/updating/deleting the service, if any
string async_operation_id = 5;

// The date and time when the service was created
google.protobuf.Timestamp created_time = 6;

// The date and time when the service was last modified
// Will not be set if the service has never been modified.
Copy link
Member

Choose a reason for hiding this comment

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

Curious why not default this to created_time? Is this for consistency with other APIs?

Copy link
Member Author

Choose a reason for hiding this comment

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

yeah, this is just for consistency. could have definitely been defaulted to created_time here

google.protobuf.Timestamp last_modified_time = 7;
}

Loading