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

feat: Support GetWorkflow regardless of its archival status #11055

Merged
merged 3 commits into from
May 22, 2023

Conversation

terrytangyuan
Copy link
Member

@terrytangyuan terrytangyuan commented May 8, 2023

This includes the backend changes for #10781.

Signed-off-by: Yuan Tang <terrytangyuan@gmail.com>
@terrytangyuan terrytangyuan marked this pull request as ready for review May 9, 2023 15:00
server/workflow/workflow_server.go Show resolved Hide resolved
@@ -15,6 +15,7 @@ message ListArchivedWorkflowsRequest {
message GetArchivedWorkflowRequest {
string uid = 1;
string namespace = 2;
string name = 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 recommend creating a new API and deprecating the existing one for supporting backward capability.

Copy link
Member Author

Choose a reason for hiding this comment

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

Introducing new API will bring more maintenance effort IMO. There are already multiple artifacts APIs that need to be refactored later. Perhaps we can add a parameter, e.g. lookUpArchived=true, to toggle this functionality to maintain compatibility?

Copy link
Member Author

Choose a reason for hiding this comment

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

Moving discussions to #10781

Copy link
Member

Choose a reason for hiding this comment

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

Is it going to be a breaking change? Is there a way we can support this feature with backward compatibility?

Copy link
Member

Choose a reason for hiding this comment

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

The change would not be considered breaking since introducing fields would not break any existing behavior. We're introducing a new name field as part of the existing request to allow users to retrieve workflows by name/namespace, but existing users who are retrieving workflow by UID would not be affected.

Copy link
Member

Choose a reason for hiding this comment

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

Thanks, @jessesuen Just had a discussion with @terrytangyuan. I request to test the using current SDK with the new Argo server(signature changes) whether it passes the "" for new arguments or user needs to update the new SDK.

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 tested this with existing SDK against the new Argo Server and existing behavior preserves. Users can still use only UID to retrieve the archived workflow.

Copy link
Member

@jessesuen jessesuen left a comment

Choose a reason for hiding this comment

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

@terrytangyuan how do we address the need for a unified list API? It's one thing to GET a workflow by namespace/name from either etcd or archive, but don't we want to improve the UX such that archived workflows could also be presented in same list view?

persist/sqldb/workflow_archive.go Outdated Show resolved Hide resolved
And(nameEqual(name)).
One(archivedWf)
} else {
return nil, fmt.Errorf("both name and namespace are required if uid is not specified")
Copy link
Member

Choose a reason for hiding this comment

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

Is there a way to return an error that would cause us to return 400 Bad Request as an http response?

Copy link
Member Author

@terrytangyuan terrytangyuan May 16, 2023

Choose a reason for hiding this comment

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

Yes, see my latest commit. Good idea.

Copy link
Member Author

@terrytangyuan terrytangyuan May 16, 2023

Choose a reason for hiding this comment

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

terrytangyuan and others added 2 commits May 16, 2023 16:52
Signed-off-by: Yuan Tang <terrytangyuan@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/api Argo Server API
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants