TUI management for resources

[mcopik]

Currently, we provide a partial list of resources from the cache. We could vibe-code a simple TUI tool to visually represent everything:

• Which benchmarks are deployed (what languages, what config, what platform)
• What resources are allocated.
• Overview of generated experimental results.

[sanskar-singh-2403]

hey @mcopik can i pick this up?

[sanskar-singh-2403]

Following up on this, and flagging that I think #305 and #306 are naturally a coupled pair.

Both operate on the same on-disk cache model: the per-cloud files (aws.json, local.json, ...) that hold resources.resources_id / storage_buckets / allocated_ports, and the per-benchmark config.json files that hold functions, storage/nosql, code_package, and containers. #305 needs to walk that model, classify each entry as allocated-cloud (keep) vs local-only (drop), and dedup by resources_id. #306's TUI needs to walk the exact same model to show "which benchmarks are deployed (language / config / platform) and what resources are allocated." So I would like to build one small reusable cache-inspection layer and have the merge command (#305) and the TUI (#306) both consume it, rather than parsing the cache twice.

To unblock myself I have picked defaults for the earlier scope questions, so you can just confirm or correct:

1. Surface: a new sebs.py cache merge <cache_a> <cache_b> ... -o <out> command, grouped like the existing resources / docker command groups. Inputs are read-only, output is a fresh cache dir.
2. Conflict on the same resources_id with differing values: fail loudly by default, with an opt-in --on-conflict {fail,first,last} flag. Entries keyed by a unique cloud name (functions, buckets) are unioned and never need resolution; the flag only matters for genuine same-key value divergence.
3. "Local resources" to drop for portability: allocated_ports, code_package.location and the copied build artifacts on disk (code/ dirs and zip files), and container image-id. Kept as portable: resources_id, storage_buckets, functions, storage/nosql, and container image-uri (registry-addressable).

If that direction looks right, could you assign #305 (and #306, since I would build them on the shared layer) to me? Happy to open a draft PR for #305 right after.

[mcopik]

Hi @sanskar-singh-2403! Thank you for your interest in the project! Yes, both issues are related. For the first-time contribution, I would recommend this issue, as #305 needs a good understanding of our cache model; building a small visualizer starter here might be a good way to learn that.

I'm not sure if you need a cache inspection layer, as there's already an implementation in sebs.cache.Cache; you might just want to slightly expand the available API, particularly for features needed in a merge functionality.

For your exact questions:

1. The idea sounds good! Since we already have resources command, perhaps a subcommand sebs resources cache-merge?

2. Correct - this is not the intended usage. The intended usage is that we run distributed test sites but using different resources, e.g., different functions are tested. We just need to ensure that (a) we merge different object storage buckets or functions from different sites, and that (b) we drop things like locally built code packages, as these are specific to one deployment site.

3. Correct. However, we should keep containers that are exported in the cloud (with image-uri).

Once again, thank you for the interest and let me know how it goes!

[sanskar-singh-2403]

Hey @mcopik, Thanks!

Started on this. I have an initial implementation up as a PR.

Following your steer, I kept it as a read-only view built directly on the existing sebs.cache.Cache rather than a separate inspection layer, and put it under the existing resources command group as sebs resources inspect. It does not contact any cloud provider and does not require a Docker daemon, so it works purely off the on-disk cache.

What it surfaces:

• Deployed benchmarks: benchmark, platform, language, packaging (container vs code_package), function count, and trigger types.
• Allocated resources per platform: resources_id, region, storage bucket count, and locally allocated ports.

Two small Cache API additions back it:

• get_deployed_benchmarks() walks the per-benchmark config.json files.
• get_allocated_resources() reads the per-cloud files (aws.json, local.json, ...).

I also made Cache's docker_client optional so read-only consumers can open a cache without Docker running (the container-caching paths are guarded with an assertion).

Usage:

sebs resources inspect --cache ./cache
sebs resources inspect --cache ./cache --deployment aws
sebs resources inspect --cache ./cache --output json

Includes offline unit tests over a synthetic cache. Happy to adjust the columns or output shape. Once the model is nailed down here, I can build the #305 merge command on the same Cache helpers.