-
Notifications
You must be signed in to change notification settings - Fork 220
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
Add deployment API #1733
Conversation
There was a problem hiding this 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
internal/deployment_client.go
Outdated
DeploymentClient interface { | ||
// Describes an existing deployment. | ||
// NOTE: Experimental | ||
Describe(ctx context.Context, deploymentID Deployment) (DeploymentInfo, error) |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Never mind. we may want other options that limit what Deployment
is already a struct, so that will give us a escape hatch if we need a deployment id with other fields.Describe
or GetReachability
shows, adding wrappers too...
Adding DeploymentGetCurrentOptions
that was just a string argument...
internal/deployment_client.go
Outdated
Deployment Deployment | ||
|
||
// ClientIdentity - Optional: The identity of the client who initiated this request. | ||
ClientIdentity string |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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{} |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: should be experimental
CreateTime time.Time | ||
|
||
// Current - Whether this deployment is the current one for its deployment series. | ||
Current bool |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
What was changed
This PR implements the new deployment API needed for worker versioning. It provides a new
DeploymentClient
that has methods:Checklist
Support the Deployment API #1713
Unit tests following the ScheduleClient template. System tests in a separate PR when there is a server that supports it.