fix: use configurable GPU resource name instead of hardcoded nvidia.com/gpu

[nuthalapativarun]

Tracking issue

Closes #6746

Why are the changes needed?

Two code paths hardcoded "nvidia.com/gpu" when building Kubernetes ResourceList entries from Flyte GPU resource requirements. This hardcoding took precedence over the GpuResourceName field already configurable in K8sPluginConfig (via the gpu-resource-name Helm/propeller config value), making it impossible to use alternative GPU resource types such as amd.com/gpu or intel.com/gpu.

The affected paths were:

• flyteplugins/go/tasks/pluginmachinery/flytek8s/utils.go — ToK8sResourceList used the package-level ResourceNvidiaGPU constant.
• flytepropeller/pkg/controller/nodes/task/taskexec_context.go — convertTaskResourcesToRequirements used utils.ResourceNvidiaGPU.

Note that SanitizeGPUResourceRequirements and ApplyResourceOverrides in container_helper.go already correctly read from config.GetK8sPluginConfig().GpuResourceName. This PR brings the two remaining call sites into alignment.

What changes were proposed in this pull request?

• flyteplugins/.../flytek8s/utils.go: Import flytek8s/config and replace ResourceNvidiaGPU with config.GetK8sPluginConfig().GpuResourceName in ToK8sResourceList.
• flytepropeller/.../taskexec_context.go: Import flytek8s/config and replace utils.ResourceNvidiaGPU with flytek8sConfig.GetK8sPluginConfig().GpuResourceName in convertTaskResourcesToRequirements. Remove now-unused flytepropeller/pkg/utils import.
• Tests: Update both test files to assert against config.GetK8sPluginConfig().GpuResourceName rather than the hardcoded constant, confirming the behavior is config-driven.

How was this patch tested?

• go test ./go/tasks/pluginmachinery/flytek8s/... in flyteplugins/ — passes.
• go test ./pkg/controller/nodes/task/... in flytepropeller/ — passes.

Labels

• fixed

• I updated the documentation accordingly.

• All new and existing tests passed.

• All commits are signed-off.

[Sovietaced]

I've fixed this in our company's fork and I believe it was more involved than this due to handling of pod templates and needing to normalize the dummy GPU resource name to the configured one. If you can wait a week or two I can probably pull that work into master.

[Sovietaced]

I've fixed this in our company's fork and I believe it was more involved than this due to handling of pod templates and needing to normalize the dummy GPU resource name to the configured one. If you can wait a week or two I can probably pull that work into master.

Oh this looks like some drive by AI assisted pull request so I'll wait to review this until I get back from vacation.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 56.95%. Comparing base (e938b03) to head (1ee6ed9).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #7237      +/-   ##
==========================================
- Coverage   56.96%   56.95%   -0.01%     
==========================================
  Files         931      931              
  Lines       58246    58247       +1     
==========================================
- Hits        33178    33173       -5     
- Misses      22014    22020       +6     
  Partials     3054     3054              

Flag	Coverage Δ
unittests-datacatalog	53.51% <ø> (ø)
unittests-flyteadmin	53.10% <ø> (-0.04%)	⬇️
unittests-flytecopilot	43.06% <ø> (ø)
unittests-flytectl	64.14% <ø> (ø)
unittests-flyteidl	75.71% <ø> (ø)
unittests-flyteplugins	60.17% <100.00%> (ø)
unittests-flytepropeller	53.71% <100.00%> (+<0.01%)	⬆️
unittests-flytestdlib	62.61% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[kumare3]

This has been greatly improved in v2, check the v2 branch - close
To release

[nuthalapativarun]

Thanks for the context, @Sovietaced — happy to expand the scope to cover pod template normalization and dummy GPU resource name handling as well. If you can point me to the relevant code paths (or describe what your fork's fix looks like at a high level), I can incorporate that before your review. No rush given the vacation timeline.

@kumare3 — do you mean this should target the v2 branch instead of master, or that the issue is already resolved there and this PR should be closed? Happy to follow whichever path makes more sense for the project.