-
Notifications
You must be signed in to change notification settings - Fork 42
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 omdb commands for printing basic saga information #7695
base: main
Are you sure you want to change the base?
Conversation
Running it against
|
This is more duplicative with #4378 than I realized. I'm sorry about that! It may make sense to just close this in favor of that one, but maybe some of the stuff here can be useful for doing pagination, printing as much as possible when we fail to load stuff, etc. I'm also not sure that one's |
Breaking apart #4378 and copying the structure of #7695, add `omdb db saga` as a command and implement the following sub-commands: Usage: omdb db saga [OPTIONS] <COMMAND> Commands: running List running sagas fault Inject an error into a saga's currently running node This addresses part of the minimum amount required during a release deployment: 1. after quiescing (#6804), omdb can query if there are any running sagas. 2. if those running sagas are stuck in a loop and cannot be drained (#7623), and the release contains a change to the DAG that causes Nexus to panic after an upgrade (#7730), then omdb can inject a fault into the database that would cause that saga to unwind when the affected Nexus is restarted Note for 2, unwinding a saga that is stuck in this way may not be valid if there were significant changes between releases.
I'm going to be breaking apart 4378, and am taking your suggestion about using some the structure of this PR for that. I opened #7732 for this. Thanks for all the reviews :) |
This adds two commands:
omdb db saga running
: list running sagasomdb db saga details SAGA_ID
: print detailed information about one sagaThis definitely overlaps with #4378 but I tried not to re-implement anything here that I remember being implemented there.
Related: #4157, #7623