[WRK-814] Client side impl Sandbox.resource_usage()

[thundergolfer]

Describe your changes

• WRK-814

---

Check these boxes or delete any item (or this section) if not relevant for this PR.

• Client+Server: this change is compatible with old servers
• Client forward compatibility: this change ensures client can accept data intended for later versions of itself

Note on protobuf: protobuf message changes in one place may have impact to
multiple entities (client, server, worker, database). See points above.

---

Changelog

• Adds new Sandbox.resource_usage() method to retrieve billable resource usage (CPU, RAM, GPU time).

[devennavani]

LGTM. It might be good to clarify in the comments/docstring that the returned CPU and memory values are max(used, requested)

[mwaskom]

Currently we have a many-to-one mapping for some GPU types on configuration (e.g. we accept "A10" and "A10g", plus we're case-insensitive, etc. How are we defining the schema for GPU type here? We've broken our own internal tooling recently with some migrations; are we now obligated to keep the current schema fixed moving forward?

[thundergolfer]

Hmm, I think it's possible we do modify them. Unlikely but possible.

I'm inclined to drop the field then and make the user maintain a mapping from sandbox ID -> their own GPU type.

[erikbern]

We have a canonical map in the backend, could just use that one. But I'm also fine not exposing it here.

[mwaskom]

that makes sense to me in general but do sandboxes have gpu fallbacks? or can you only request one gpu type?

[mwaskom]

Random ignorable suggestion but nanosecs is super non-human-friendly, maybe the dataclass could have a method that presents the underlying data in a more human-readable format to save people some hassle when they're using it interactively or printing it or whatever.

[thundergolfer]

Yep good idea, I can do a nice repr.

[thundergolfer]

Hmm, maybe not repr, I like this behavior:

Return a string containing a printable representation of an object. For many types, this function makes an attempt to return a string that would yield an object with the same value when passed to eval();

[mwaskom]

Personally I've never thought that notion of repr() was very useful, but yeah I think you could do it with __str__ instead of __repr__, or some named method that returns a string. I'd probably try to format the CPU/RAM/GPU usage with SI prefixes so it's readable across multiple OOMs.

[mwaskom]

LGTM. It might be good to clarify in the comments/docstring that the returned CPU and memory values are max(used, requested)

oh missed that as I haven’t looked closely at the backend pr, but would argue that maybe suggests a different name, not just documentation (which is also good to add).

[mwaskom]

I think different people might really want to know both though (what did it actually use, eg for profiling, and what did we bill for, eg for passing on costs).

[mwaskom]

And ideally we wouldn’t expose multiple variants of similar information through multiple different ad hoc methods :/. Maybe an as_billed: bool parameter or something?

[thundergolfer]

Maybe an as_billed: bool parameter or something?

Like resource_usage(raw: bool = True)? If raw==True then pass through the usage, otherwise apply the reservation and regional modifiers.

Hmm I don't love it. I didn't realize that we applied compute resource multipliers because of region scheduling. I'd otherwise be OK with passing through the reserved value as-is, because I don't think this endpoint can ever serve as profiling data.

I'll leave this for a bit and think about it.

[mwaskom]

Like resource_usage(raw: bool = True)? If raw==True then pass through the usage, otherwise apply the reservation and regional modifiers.

I am just suggesting that we allow users to query used or max(used, reserved). I don't think this endpoint should reflect any modifiers which I see as a sort of implementation detail.

I'd otherwise be OK with passing through the reserved value as-is,

If you do that IMO I'd say it's mandatory to name the method differently; how can we describe the billing as applying to max(used, reserved) and then call the resulting value "usage"?

I don't think this endpoint can ever serve as profiling data

Why not? I'd certainly try to use it for something like that based on how it's currently presented, and I expect other users would too.