Nick Stogner

I think this would be better implemented as configurable gpu-types. Currently GPU types are hardcoded here: https://github.com/substratusai/substratus/blob/main/internal/resources/gpu_info.go This mapping could be pulled from a ConfigMap in the substratus namespace instead....

If users only specify GPU count and not type they will be under specifying the memory required (which is implied in gpu-type today). Perhaps we allow users to EITHER specify...

Let me know what your thoughts are on my previous comment.

Alternative: `diskGB:`. Is there ever a need for fractional units? The native pod resource specification comes with some possible confusion around whether you are using binary or decimal: https://pkg.go.dev/k8s.io/apimachinery/pkg/api/resource#pkg-constants

`diskGB` and `memoryGB` make sense to me. I wonder if `cpuCount` is needed over `cpu`?

Minio's copyleft license might become a liability for users here: https://github.com/minio/minio/blob/master/LICENSE

Still applicable for the new `kubectl applybuild` command. Change should probably be made here: https://github.com/substratusai/substratus/blob/cce660ba0513032031fdddaf43e359f26dab9463/kubectl/internal/client/upload.go#L131

The scenario where one object created another object is typically tracked with owner references in kubernetes: https://kubernetes.io/docs/concepts/overview/working-with-objects/owners-dependents/

Once we start enforcing immutability of `.spec` fields we will be able to trust the lineage specified there (i.e. `.spec.trainingDataset` in a Model).

The registry url is configurable using this env variable on the controller: https://github.com/substratusai/substratus/blob/20b755fdc1d85fb9b800a7eb13610a027eeb3545/internal/cloud/common.go#L15 However, we have never tried using any registry other than Google Artifact Registry.