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

Add deployment API #1733

Merged

Conversation

antlai-temporal
Copy link
Contributor

What was changed

This PR implements the new deployment API needed for worker versioning. It provides a new DeploymentClient that has methods:

Describe(ctx context.Context, deploymentID Deployment) (DeploymentInfo, error)
List(ctx context.Context, options DeploymentListOptions) (DeploymentListIterator, error)
GetReachability(ctx context.Context, deploymentID Deployment) (DeploymentReachabilityInfo, error)
GetCurrent(ctx context.Context, seriesName string) (DeploymentInfo, error)
SetCurrent(ctx context.Context, options DeploymentSetCurrentOptions) (DeploymentSetCurrentResponse, error)

Checklist

  1. Closes
    Support the Deployment API #1713
  2. How was this tested:

Unit tests following the ScheduleClient template. System tests in a separate PR when there is a server that supports it.

@antlai-temporal antlai-temporal requested a review from a team as a code owner December 2, 2024 02:55
Copy link
Member

@cretz cretz left a comment

Choose a reason for hiding this comment

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

Mostly LGTM, one slight suggestion

DeploymentClient interface {
// Describes an existing deployment.
// NOTE: Experimental
Describe(ctx context.Context, deploymentID Deployment) (DeploymentInfo, error)
Copy link
Member

Choose a reason for hiding this comment

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

I wonder if for Describe and GetCurrent you'd rather have options structures just to be future proof (Go is a bit annoying here w/ no overloads or optional params).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Makes sense, it will be a bit more annoying to use but it is worth avoiding a DescribeWithOptions...

Copy link
Contributor Author

@antlai-temporal antlai-temporal Dec 2, 2024

Choose a reason for hiding this comment

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

Deployment is already a struct, so that will give us a escape hatch if we need a deployment id with other fields. Never mind. we may want other options that limit what Describe or GetReachability shows, adding wrappers too...
Adding DeploymentGetCurrentOptions that was just a string argument...

Deployment Deployment

// ClientIdentity - Optional: The identity of the client who initiated this request.
ClientIdentity string
Copy link
Contributor

Choose a reason for hiding this comment

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

Why are we not using the client identity , I think that is what every other call uses.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point, I'll send the client identitiy as default, they may want to override it for versioning...

Copy link
Contributor

Choose a reason for hiding this comment

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

No other call in the SDK needed an override, I would leave off until there is an ask

// UpsertEntries - Metadata entries inserted or modified. When values are not
// of type *commonpb.Payload, the default data converter will be used to generate
// payloads.
UpsertEntries map[string]interface{}
Copy link
Contributor

Choose a reason for hiding this comment

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

the default data converter will be used to generate payloads.

Why? does the Temporal server need to read these?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The idea of payloads was to support encryption. Converting to payloads transparently in UpsertEntries was just for convenience, they can always pass payloads if they want...

Copy link
Contributor

Choose a reason for hiding this comment

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

We should use the clients data converter here then

Copy link
Contributor

@Quinn-With-Two-Ns Quinn-With-Two-Ns Dec 2, 2024

Choose a reason for hiding this comment

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

We should only use the default data converter if the server needs to read the payload

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm using converter.GetDefaultDataConverter().ToPayload, I thought that would give me client data converter, which one should I be using?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I see getDataConverterFromWorkflowContext() may give me what I need, it defaults to the default data converter if none provided...

Copy link
Contributor

@Quinn-With-Two-Ns Quinn-With-Two-Ns Dec 2, 2024

Choose a reason for hiding this comment

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

WorkflowClient.dataConverter

dataConverter converter.DataConverter

Copy link
Contributor

Choose a reason for hiding this comment

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

GetDefaultDataConverter() is a program wide data converter, not the clients

Copy link
Contributor

Choose a reason for hiding this comment

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

Server does not need to read these.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

@@ -417,6 +417,9 @@ type (
// Schedule creates a new shedule client with the same gRPC connection as this client.
ScheduleClient() ScheduleClient

// DeploymentClient creates a new deployment client with the same gRPC connection as this client.
DeploymentClient() DeploymentClient
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: should be experimental

@antlai-temporal antlai-temporal merged commit 34b1096 into temporalio:versioning-3 Dec 3, 2024
12 checks passed
CreateTime time.Time

// Current - Whether this deployment is the current one for its deployment series.
Current bool
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: wouldn't IsCurrent be more more idiomatic?

CreateTime time.Time

// Whether this deployment is the current one for its deployment series.
Current bool
Copy link
Contributor

Choose a reason for hiding this comment

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

same


// LastUpdateTime - When reachability was last computed. Computing reachability
// is an expensive operation, and the server caches results.
LastUpdateTime time.Time
Copy link
Contributor

Choose a reason for hiding this comment

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

hmm.. if we embed DeploymentInfo there would be timestamps such CreateTime besides this LastUpdateTime, user wouldn't know if the field only refers to reachability status update time. Later more timestamps and other fields will be added to Deployment Info (and maybe to Reachability response) and I worry it'd be confusing for users if we mix them. Should we make deployment info just a nested field instead of an embed?

@antlai-temporal antlai-temporal mentioned this pull request Dec 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants