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 Pre-Release APIs #479

Merged
merged 6 commits into from
Nov 19, 2024
Merged
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
855 changes: 734 additions & 121 deletions openapi/openapiv2.json

Large diffs are not rendered by default.

567 changes: 547 additions & 20 deletions openapi/openapiv3.yaml

Large diffs are not rendered by default.

21 changes: 0 additions & 21 deletions temporal/api/common/v1/message.proto
Original file line number Diff line number Diff line change
Expand Up @@ -37,7 +37,6 @@ import "google/protobuf/empty.proto";
import "temporal/api/enums/v1/common.proto";
import "temporal/api/enums/v1/event_type.proto";
import "temporal/api/enums/v1/reset.proto";
import "temporal/api/enums/v1/workflow.proto";

message DataBlob {
temporal.api.enums.v1.EncodingType encoding_type = 1;
Expand Down Expand Up @@ -157,26 +156,6 @@ message WorkerVersionCapabilities {
// Later, may include info like "I can process WASM and/or JS bundles"
}

// Used in both UpdateWorkflowExecutionOptions and StartWorkflowExecution to override
// the versioning behavior of a specific workflow execution. If set, takes precedence
// over the sdk-sent Versioning Behavior for the specific Workflow Execution it is set on.
// To remove the override, call UpdateWorkflowExecutionOptions with a null VersioningBehaviorOverride,
// and use the FieldMask to indicate that it should be mutated.
message VersioningBehaviorOverride {
// Required.
temporal.api.enums.v1.VersioningBehavior behavior = 1;

// Required if behavior is `PINNED`. Must be null if behavior is `AUTO_UPGRADE`.
// Identifies the Build ID and Deployment Name to pin the workflow to.
WorkerDeployment worker_deployment = 2;
}

// Identifies a versioned worker deployment.
message WorkerDeployment {
string deployment_name = 1;
string build_id = 2;
}

// Describes where and how to reset a workflow, used for batch reset currently
// and may be used for single-workflow reset later.
message ResetOptions {
Expand Down
69 changes: 69 additions & 0 deletions temporal/api/deployment/v1/message.proto
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
// The MIT License
//
// Copyright (c) 2020 Temporal Technologies Inc. All rights reserved.
//
// Permission is hereby granted, free of charge, to any person obtaining a copy
// of this software and associated documentation files (the "Software"), to deal
// in the Software without restriction, including without limitation the rights
// to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
// copies of the Software, and to permit persons to whom the Software is
// furnished to do so, subject to the following conditions:
//
// The above copyright notice and this permission notice shall be included in
// all copies or substantial portions of the Software.
//
// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
// AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
// LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
// OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
// THE SOFTWARE.

syntax = "proto3";

package temporal.api.deployment.v1;

option go_package = "go.temporal.io/api/deployment/v1;deployment";
option java_package = "io.temporal.api.deployment.v1";
option java_multiple_files = true;
option java_outer_classname = "MessageProto";
option ruby_package = "Temporalio::Api::Deployment::V1";
option csharp_namespace = "Temporalio.Api.Deployment.V1";

import "google/protobuf/timestamp.proto";

import "temporal/api/enums/v1/deployment.proto";
import "temporal/api/enums/v1/task_queue.proto";
import "temporal/api/common/v1/message.proto";

// Identifies a worker deployment. A worker deployment is identified by the combination of
// deployment name + build ID. Both values are required.
message Deployment {
string deployment_name = 1;
ShahabT marked this conversation as resolved.
Show resolved Hide resolved
string build_id = 2;
}

// Holds information about a worker deployment.

Choose a reason for hiding this comment

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

this comment doesn't add much information. Should define "deployment"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added more information for both Deployment and DeploymentInfo.

message DeploymentInfo {
Deployment deployment = 1;
enums.v1.DeploymentStatus status = 2;
ShahabT marked this conversation as resolved.
Show resolved Hide resolved
google.protobuf.Timestamp status_change_time = 3;
// A user-defined set of fields. Can be updated via other write operations to the deployment,
// such as SetCurrentDeployment.
common.v1.Memo memo = 4;
ShahabT marked this conversation as resolved.
Show resolved Hide resolved
repeated TaskQueueInfo task_queues_info = 5;
ShahabT marked this conversation as resolved.
Show resolved Hide resolved

message TaskQueueInfo {
string task_queue_name = 1;
enums.v1.TaskQueueType task_queue_type = 2;
// When server saw the first poller for this task queue in this deployment.
google.protobuf.Timestamp first_poller_time = 3;
Copy link
Member

Choose a reason for hiding this comment

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

I would add last_poller_time if technically possible. Can be updated lazily.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👍 That's possible and I agree we should have it. Will create a task for it (can't do right away because of more technical work).

Copy link
Member

Choose a reason for hiding this comment

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

I don't think it belongs here. As this time is per build id. Or this message should be renamed to the DeploymentTaskQueueInfo

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 message is already nested in DeploymentInfo so I thought it's less verbose like this. But please lmk if you think it should still be renamed to DeploymentTaskQueueInfo.

Copy link
Member

Choose a reason for hiding this comment

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

Message names are top level. So someone looking at the name will not see where it is used.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@mfateev This message name is nested, not top level. Are suggesting we should not have nested message definitions and only top level?

}
}

// Used as part of Deployment write APIs to update metadata attached to a deployment.
message UpdateDeploymentMemo {
common.v1.Memo upsert_entries = 1;
repeated string remove_entries = 2;
}
66 changes: 66 additions & 0 deletions temporal/api/enums/v1/deployment.proto
Original file line number Diff line number Diff line change
@@ -0,0 +1,66 @@
// The MIT License
//
// Copyright (c) 2020 Temporal Technologies Inc. All rights reserved.
//
// Permission is hereby granted, free of charge, to any person obtaining a copy
// of this software and associated documentation files (the "Software"), to deal
// in the Software without restriction, including without limitation the rights
// to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
// copies of the Software, and to permit persons to whom the Software is
// furnished to do so, subject to the following conditions:
//
// The above copyright notice and this permission notice shall be included in
// all copies or substantial portions of the Software.
//
// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
// AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
// LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
// OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
// THE SOFTWARE.

syntax = "proto3";

package temporal.api.enums.v1;

option go_package = "go.temporal.io/api/enums/v1;enums";
option java_package = "io.temporal.api.enums.v1";
option java_multiple_files = true;
option java_outer_classname = "DeploymentProto";
option ruby_package = "Temporalio::Api::Enums::V1";
option csharp_namespace = "Temporalio.Api.Enums.V1";

// Status of a deployment. Among all deployments with shared deployment name, at most one can have
// `RAMPING` status, and at most one can have `CURRENT` status.
//
// (-- api-linter: core::0216::synonyms=disabled
// aip.dev/not-precedent: This enum specifies the status of the deployment among all deployments
// of the same name, therefore `DeploymentStatus` is a better name that `DeploymentState`. --)
enum DeploymentStatus {
DEPLOYMENT_STATUS_UNSPECIFIED = 0;
// The deployment does not have a special status.
DEPLOYMENT_STATUS_NO_STATUS = 1;
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we need this? is UNSPECIFIED not enough? Clarify in the comments...

// The deployment is the ramping deployment for the deployment name.
DEPLOYMENT_STATUS_RAMPING = 2;
// The deployment is the current deployment for the deployment name.
DEPLOYMENT_STATUS_CURRENT = 3;
Copy link
Member

Choose a reason for hiding this comment

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

Should we consider a future when we are able to use a different current deployment for different workflow types or task queues? To me it looks like we need a separate Table/Message/API to get all Start/ContinueAsNew records that point to deployments.

Copy link

@drewhoskins-temporal drewhoskins-temporal Nov 19, 2024

Choose a reason for hiding this comment

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

We've thought about some of these cases:

  • for task queues, at least on our current roadmap, we'll insist that users create a different deployment series if they want to rollout task queues separately. (Note that we will support the ability to move a task queue from one deployment series to another) We don't see this as being a big burden for such an advanced use case.
  • for workflow types, we've decided to lean on the UpdateWorkflowOptions for these power-user scenarios for now. (or they can create a different deployment series) But you could imagine adding more fine-grained control to the rollout API. (i.e. instead of a single % ramp, we could provide various ramps for different types. Shahab mentioned there could be multi-cursor problems to think about with such, though). In that world, we could keep the high-level status of DEPLOYMENT_STATUS_RAMPING and create a more fine-grained API for power users. So, it seems premature to think too deeply now.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Adding to @drewhoskins-temporal comments, basically we envision eventually adding task queue and workflow type granularity to Rollout so user can ramp them one-by-one. However, setting different current deployment for different workflow types or task queues is not currently on the road map and users should create new deployment series for such cases.

}

// Specify the reachability level for a deployment so users can decide if it is time to
// decommission the deployment.
enum DeploymentReachability {
// Reachability level is not specified.
DEPLOYMENT_REACHABILITY_UNSPECIFIED = 0;
// The deployment is reachable by open workflows that can only run on this deployment. The
// deployment cannot be decommissioned safely.
DEPLOYMENT_REACHABILITY_OPEN_WORKFLOWS = 1;
// The deployment is not reachable by open workflows but might be still needed by closed
// workflows who can only run Queries on this deployment. The deployment can be decommissioned
// safely if user does not query closed workflows.
DEPLOYMENT_REACHABILITY_CLOSED_WORKFLOWS_ONLY = 2;
// The deployment is not reachable by any workflow because all the workflows who needed this
// deployment went out of retention period. The deployment can be decommissioned
// safely.
DEPLOYMENT_REACHABILITY_UNREACHABLE = 3;
}
ShahabT marked this conversation as resolved.
Show resolved Hide resolved
5 changes: 3 additions & 2 deletions temporal/api/history/v1/message.proto
Original file line number Diff line number Diff line change
Expand Up @@ -40,6 +40,7 @@ import "temporal/api/enums/v1/failed_cause.proto";
import "temporal/api/enums/v1/update.proto";
import "temporal/api/enums/v1/workflow.proto";
import "temporal/api/common/v1/message.proto";
import "temporal/api/deployment/v1/message.proto";
import "temporal/api/failure/v1/message.proto";
import "temporal/api/taskqueue/v1/message.proto";
import "temporal/api/update/v1/message.proto";
Expand Down Expand Up @@ -255,7 +256,7 @@ message WorkflowTaskCompletedEventAttributes {
message CompletedDeploymentRedirectInfo {
// The target deployment of the redirect. Null means a previously versioned workflow just
// completed a redirect to unversioned workers.
temporal.api.common.v1.WorkerDeployment deployment = 1;
deployment.v1.Deployment deployment = 1;
ShahabT marked this conversation as resolved.
Show resolved Hide resolved
// Versioning behavior sent by SDK for this workflow execution on the new deployment.
// Must be present if and only if `deployment` is set.
temporal.api.enums.v1.VersioningBehavior versioning_behavior = 2;
Expand All @@ -268,7 +269,7 @@ message CompletedDeploymentRedirectInfo {
message FailedDeploymentRedirectInfo {
// The target deployment of the failed redirect attempt. Null means a versioned workflow
// tried to redirect to unversioned workers.
temporal.api.common.v1.WorkerDeployment deployment = 1;
deployment.v1.Deployment deployment = 1;
}

message WorkflowTaskTimedOutEventAttributes {
Expand Down
33 changes: 24 additions & 9 deletions temporal/api/workflow/v1/message.proto
Original file line number Diff line number Diff line change
Expand Up @@ -38,6 +38,7 @@ import "google/protobuf/timestamp.proto";
import "temporal/api/enums/v1/common.proto";
import "temporal/api/enums/v1/workflow.proto";
import "temporal/api/common/v1/message.proto";
import "temporal/api/deployment/v1/message.proto";
import "temporal/api/failure/v1/message.proto";
import "temporal/api/taskqueue/v1/message.proto";
import "temporal/api/sdk/v1/user_metadata.proto";
Expand Down Expand Up @@ -107,19 +108,19 @@ message WorkflowExecutionInfo {

message VersioningInfo {
// Determines how server should treat this execution when workers are upgraded.
// When present it means that this workflow is versioned. This is not set until an execution
// When present it means that this workflow is versioned. This is set after an execution
// completes its first workflow task on a versioned worker.
temporal.api.enums.v1.VersioningBehavior behavior = 1;
// The worker deployment to which this workflow is assigned currently.
// Must be present if and only if `behavior` is set.
temporal.api.common.v1.WorkerDeployment deployment = 2;
deployment.v1.Deployment deployment = 2;
// Manual override for execution's versioning behavior. Takes precedence over `behavior`.
temporal.api.enums.v1.VersioningBehavior behavior_override = 3;
// Used to manually pin the execution to a deployment. Must be set when if and only if
// Used to manually pin the execution to a deployment. Must be set if and only if
// `behavior_override` is PINNED. Takes precedence over `deployment`.
temporal.api.common.v1.WorkerDeployment deployment_override = 4;
deployment.v1.Deployment deployment_override = 4;
// When present, indicates the workflow is being redirected to a different deployment.
// A deployment redirect can only exist during the life time of a pending workflow task.
// A redirect can only exist during the lifetime of a pending workflow task.
// If the pending workflow task completes (at the next WorkflowTaskCompleted event), the
// redirect is considered complete and the workflow's deployment is updated. If the pending
// workflow task fails or times out, then the redirect is canceled and workflow remains on
Expand All @@ -129,7 +130,7 @@ message WorkflowExecutionInfo {
message RedirectInfo {
// The target deployment of the redirect. Null means a so-far-versioned workflow is
// being redirected to unversioned workers.
temporal.api.common.v1.WorkerDeployment deployment = 1;
deployment.v1.Deployment deployment = 1;
// If present, it means the redirect is initiated by a (safe) manual versioning
// override. Such override is only applied to the workflow when and if the redirect
// successfully completes.
Expand Down Expand Up @@ -192,7 +193,7 @@ message PendingActivityInfo {

// The deployment this activity was dispatched to most recently. Present only if the activity
// was dispatched to a versioned worker.
temporal.api.common.v1.WorkerDeployment last_started_deployment = 19;
deployment.v1.Deployment last_started_deployment = 19;
}

message PendingChildExecutionInfo {
Expand Down Expand Up @@ -364,5 +365,19 @@ message NexusOperationCancellationInfo {

message WorkflowExecutionOptions {
// If set, takes precedence over the sdk-sent Versioning Behavior for the specific Workflow Execution it is set on.
temporal.api.common.v1.VersioningBehaviorOverride versioning_behavior_override = 1;
}
VersioningBehaviorOverride versioning_behavior_override = 1;
}

// Used in both UpdateWorkflowExecutionOptions and StartWorkflowExecution to override
// the versioning behavior of a specific workflow execution. If set, takes precedence
// over the sdk-sent Versioning Behavior for the specific Workflow Execution it is set on.
// To remove the override, call UpdateWorkflowExecutionOptions with a null VersioningBehaviorOverride,
// and use the FieldMask to indicate that it should be mutated.
ShahabT marked this conversation as resolved.
Show resolved Hide resolved
message VersioningBehaviorOverride {
// Required.
enums.v1.VersioningBehavior behavior = 1;

// Required if behavior is `PINNED`. Must be null if behavior is `AUTO_UPGRADE`.
// Identifies the worker deployment to pin the workflow to.
deployment.v1.Deployment deployment = 2;
}
68 changes: 68 additions & 0 deletions temporal/api/workflowservice/v1/request_response.proto
Original file line number Diff line number Diff line change
Expand Up @@ -39,12 +39,14 @@ import "temporal/api/enums/v1/failed_cause.proto";
import "temporal/api/enums/v1/query.proto";
import "temporal/api/enums/v1/reset.proto";
import "temporal/api/enums/v1/task_queue.proto";
import "temporal/api/enums/v1/deployment.proto";
import "temporal/api/enums/v1/update.proto";
import "temporal/api/activity/v1/message.proto";
import "temporal/api/common/v1/message.proto";
import "temporal/api/history/v1/message.proto";
import "temporal/api/workflow/v1/message.proto";
import "temporal/api/command/v1/message.proto";
import "temporal/api/deployment/v1/message.proto";
import "temporal/api/failure/v1/message.proto";
import "temporal/api/filter/v1/message.proto";
import "temporal/api/protocol/v1/message.proto";
Expand Down Expand Up @@ -1737,3 +1739,69 @@ message UpdateWorkflowExecutionOptionsResponse {
// Workflow Execution options after update.
temporal.api.workflow.v1.WorkflowExecutionOptions workflow_execution_options = 1;
}

message DescribeDeploymentRequest {
string namespace = 1;
deployment.v1.Deployment deployment = 2;
}

message DescribeDeploymentResponse {
deployment.v1.DeploymentInfo deployment_info = 1;
}

message ListDeploymentsRequest {
ShahabT marked this conversation as resolved.
Show resolved Hide resolved
int32 page_size = 1;
bytes next_page_token = 2;
string namespace = 3;
// Optional. Use to filter based on deployment name.
string deployment_name = 4;
ShahabT marked this conversation as resolved.
Show resolved Hide resolved
}

message ListDeploymentsResponse {

Choose a reason for hiding this comment

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

Can we clarify the ordering of the results in a comment here?

Copy link
Contributor Author

@ShahabT ShahabT Nov 19, 2024

Choose a reason for hiding this comment

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

This is going to be roughly sorted based on deployment creation time, decending. Although if a deployment has a very high number of TQs (or very high number of events happening to it) it will CaN and the sort will be mixed up. In reality we are relying on Visibility sort which is based on WF start time.

I prefer to keep this unspecified until we have a guaranteed order in the future.

Copy link

@drewhoskins-temporal drewhoskins-temporal Nov 19, 2024

Choose a reason for hiding this comment

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

Something's not right here. I don't see a use case for listing all the deployments, intermixed, regardless of deployment name. The two scenarios I can think of are users asking:
a) what are the deployment series? (or perhaps the current deployment for each series)
b) what's the history of a given deployment series?

If users do want them all in one endpoint, or if we want that for our UI, it would be a list of lists. But that seems puntable for the unblock , here.

Copy link

@drewhoskins-temporal drewhoskins-temporal Nov 19, 2024

Choose a reason for hiding this comment

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

I also question the value of an undisclosed, flaky ordering. Users will naturally expect a time-reverse ordering regardless of what we say here.
I would say a total ordering should be a hard requirement.
Is the scenario you mentioned very likely? Is it sufficiently unlikely to ship for the pre-release and then task up the improvement?

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 believe the shuffle is sufficiently unlikely and we can fix it after pre-release. It also won't be a total shuffle, one/few over active deployment will be at the top, the fact that they are over active might mean they are also new builds.
Regarding list of lists, I agree such a UI will make sense and likely preferable. This is something I actually tried to bring up and get attention to but was not successful. Hopefully, it will be discussed during UI work and I'll be OK changing the list APIs then.

bytes next_page_token = 1;
repeated DeploymentInfo deployments = 2;

message DeploymentInfo {
deployment.v1.Deployment deployment = 1;
enums.v1.DeploymentStatus status = 2;
google.protobuf.Timestamp status_change_time = 3;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

why redefine DeploymentInfo without metadata and task_queue_infos here?

Copy link
Contributor

Choose a reason for hiding this comment

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

so the list is smaller? is the idea that if the caller wants more detailed info they would subsequently call DescribeDeployment?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Also we don't want to make the list API expensive. For example, TQ info will not be immediately accessible from Visibility.

Copy link
Contributor

Choose a reason for hiding this comment

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

Can you call it something different to avoid confusion, like DeploymentSummary or DeploymentBriefs or something like that...

Copy link

@drewhoskins-temporal drewhoskins-temporal Nov 19, 2024

Choose a reason for hiding this comment

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

This also seems odd to me. Why do users care if this API is expensive?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@drewhoskins-temporal are you suggesting the list should return complete info of all deployments?

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 can change the name to DeploymentListEntry or DeploymentSummary. Same pattern is used for ListSchedules where we return a abbreviated set of info in the list response:

// ScheduleListInfo is an abbreviated set of values from Schedule and ScheduleInfo

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Changed it to DeploymentListInfo similar to schedules.

}

message SetCurrentDeploymentRequest {
cretz 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.

I don't think this API should exist as all changes to a deployment should happen through a rollout.

Copy link

@drewhoskins-temporal drewhoskins-temporal Nov 18, 2024

Choose a reason for hiding this comment

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

@mfateev I've been meaning to mention to you--for pre-release, we're planning to ship this lower-level API. We're working on the design for the rollout API for public preview, at which time we will support ramp pre-deploy testing as part of a bigger rollout API. Then, we can deprecate this API.
The team is currently focused on execution, but expect to review the rollout API design in December.

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 annotated this and other APIs as "Experimental" in service.proto so it's clear that they all can change or be removed in the next release.

As @drewhoskins-temporal said, this one in particular is merely a low-level placeholder until the rollout API arrives before public preview.

string namespace = 1;
deployment.v1.Deployment deployment = 2;
// Optional. The identity of the client who initiated this request.
string identity = 3;
// Optional. Use to add or remove memo entries. Memo can contain user-defined keys and values
// that are exposed when describing deployments. It is a good place for such as operator name,
// links to internal deployment pipelines, etc.
deployment.v1.UpdateDeploymentMemo update_memo = 4;
}

message SetCurrentDeploymentResponse {
deployment.v1.DeploymentInfo current_deployment = 1;
}
ShahabT marked this conversation as resolved.
Show resolved Hide resolved

// Returns the Current Deployment of a deployment name.
message GetCurrentDeploymentRequest {
string namespace = 1;
string deployment_name = 2;
}

message GetCurrentDeploymentResponse {
deployment.v1.DeploymentInfo current_deployment_info = 1;
}

message GetDeploymentReachabilityRequest {
string namespace = 1;
deployment.v1.Deployment deployment = 2;
}

message GetDeploymentReachabilityResponse {
deployment.v1.DeploymentInfo deployment_info = 1;
enums.v1.DeploymentReachability reachability = 2;
// Reachability level might come from server cache. This timestamp specifies when the value
// was actually calculated.
google.protobuf.Timestamp last_update_time = 3;
}
Loading
Loading