[omdb] TUI for inspecting support bundles #8034
Conversation
| } | ||
| } | ||
|
|
||
| // Access for: The nexus internal API |
There was a problem hiding this comment.
I might need to refactor this crate a bit, but I'm expecting we'll also add one of these for ExternalApiAccess if we want to re-use this crate in the CLI
There was a problem hiding this comment.
The need for ExternalApiAccess would be a tool consuming the support-bundle-reader-lib that a customer could use rather than omdb?
There was a problem hiding this comment.
I am expecting that:
- The CLI can add an implementation using "ExternalApiAccess" (or we can add one in this crate; I don't really care strongly where it lives).
- The CLI will depend on support-bundle-reader-lib. We could use feature flags to let them avoid building against the internal API at all.
- Customers aren't really supposed to be using omdb -- it's a support staff binary which exists in the switch zone, and requires techport access to use.
|
Friendly ping, could I get eyes on this? |
| } | ||
| } | ||
|
|
||
| // Access for: The nexus internal API |
There was a problem hiding this comment.
The need for ExternalApiAccess would be a tool consuming the support-bundle-reader-lib that a customer could use rather than omdb?
|
|
||
| async fn select_up(&mut self, count: usize) -> Result<()> { | ||
| self.selected = self.selected.saturating_sub(count); | ||
| if matches!(self.file, FileState::Open { .. }) { |
There was a problem hiding this comment.
Hmm maybe I am missing something, but if a file is in the "open" state, why do we proceed to open_and_buffer? Unless the naming is weird wouldn't we be opening the file if it's currently closed?
There was a problem hiding this comment.
I think I understand now that I read some more of the code, but doesn't navigating around cause us to call open_and_buffer again on a potentially already opened file that the toggle method has already setup for us? It seems like maybe we want to check if the access is also None?
There was a problem hiding this comment.
This is implemented intentionally, but maybe I can make it more clear in the code:
- When the TUI starts, you see the index of files
- When you move up/down, you're selecting a different file. The files are still closed though
- If you press enter, you'll open a file - this is where we buffer the contents
- If you now move up/down, you're selecting a different file. In this case: the file was open, but you're picking a new file. We want to buffer the new contents, in this case.
I'll add some comments here to make this more clear, and trigger explicitly when self.selected changes
Adds the
omdb nexus sb inspectcommand, which includes a dashboard that can be used inspect support bundles.dev-tools/omdb/src/bin/omdb/nexus.rsincludes the integration of this command. Support bundles may be accessed by: UUID, path, or by "most recently created".dev-tools/support-bundle-reader-libexposes a dashboard for actually running a TUI. This TUI acts on a dynamicSupportBundleAccessortrait, which can implement a file-opening and file-reader interface, regardless of where the support bundle is stored.dev-tools/support-bundle-reader-lib/src/dashboard.rsactually implements the ratatui interface, which allows users to inspect parts of the support bundle, and optionally dump the contents of the bundles to stdout.