Cadence tools refactoring for service

uber / cadence

Cadence is a distributed, scalable, durable, and highly available orchestration engine to execute asynchronous long-running business logic in a scalable and resilient way.

https://cadenceworkflow.io

MIT License

8.21k stars 791 forks source link

Cadence tools refactoring for service #4289

Open longquanzheng opened 3 years ago

longquanzheng commented 3 years ago

Is your feature request related to a problem? Please describe. Currently a lot of features are written in CLI and not able to be used by service API. For example: reset commmand, batch command, admin delete workflow command, etc.

Proposed Solution Refactor the code in tools/ especially CLI into a way that can be built for both CLI and also a service. https://github.com/uber/cadence/tree/master/tools/cli

Several options for being a service:

Add to current frontend service
Create a new service in this repo
Create new service in a new repo : this will make releasing versions easier

Additional context No

yycptt commented 3 years ago

👍 Totally agree for commands like batch-reset, etc.

For admin DB operation commands (for example adm delete workflow) I actually prefer to keep them separate from becoming part of cadence services. We can share the code, but making them a service API may make incident mitigation harder I guess? Like if cadence service is down due to some bad workflows and we require talking to cadence service to delete the bad workflows.

longquanzheng commented 3 years ago

Right. I think only certain commands are needed. We certainly don't need to do for all.

Like if cadence service is down due to some bad workflows and we require talking to cadence service to delete the bad workflows.

Actually what I am suggested is to let existing CLI to do the same thing. E.g. deleting workflows should still talk to DB, resetting should still replaying history locally(so that it won't consume frontend's memory which may bring down the cluster)