Add cloud option to show datacenter for the gpus #182
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New ability to see which GPU type is present in which Secure Cloud data center
Add cloud option to show datacenter for the gpus (closes #181)
Example output:
And when no datacenter mapping exists on the backend, such as for GPU options that aren't available in a Runpod managed DC
The only gotcha people have to keep in mind is that the prices will be the community (lowest) prices when not explicitly giving the -s/--secure flag. But that was already the case before this patch so nothing has changed in this regard. The only reason I'm pointing this out is that it might be a bit deceptive to see the community prices by default, or when "-c" is provided, and still see the DC mapping. If the user doesn't recognize that the DCs are for the listed GPU types, not the prices in those DCs for that type, they may make incorrect assumptions about the price for running the GPU in secure cloud.
I did consider this conundrum a bit and initially only presented the DCs when -s/--secure was provided. However I found that to be rather annoying since it precluded answering the questions "Which GPUs in community cloud do Runpod also offer in a secure cloud variant?", as well as "What are all the possible GPUs, and for those that run in DCs, where can I find them?"
Those two questions prompted the current implementation of showing the DC mapping whenever there is a DC that has that GPU.
Finally, there is a reason I'm not using a comma-space delimiter; Line wrapping. I find that highly annoying for a CLI, and I think the GPU type field is a perfect example. If you grep on the line "4000 Ada" you expect to get the complete type name that you can copy-paste into wherever you need it (like the create pod subcommand), but that doesn't work. The Generation suffix is required and got line-broken so doesn't end up in the grep output, leading to user frustration. As such I wanted to ensure users could grep on their "favorite" DCs and be sure to get the complete context for that DC, with all the GPUs. This would not have been possible if I'd allowed the table writer to line-break the DC CSV strings.
How I tested it
Via interactive debugging of GraphQL interaction, unmarshalling and branching correctness.