fix: respect plugin GeneratedNameMaxLength in k8s PluginManager

[falloficaruss]

Fixes #7607

Tracking issue

Fixes #7607

When a Ray task runs as a sub-action (i.e. it is launched from a parent workflow or driver task rather than being the root action), the generated resource name follows the format {run}-{action}-{attempt} (e.g., rqfn7vfrdp9j84q86stm-a0d7xyznuli5is847rvhzlkly-0 ), which is typically 48 characters.

However, KubeRay has a strict metadata validation constraint restricting RayJob names to a maximum of 47 characters. When this limit is exceeded, KubeRay rejects the metadata creation request, causing the workflow task to hang indefinitely.

To prevent this, the Ray task plugin declares a GeneratedNameMaxLength of 47 in its properties. But the unified Kubernetes plugin manager ( PluginManager ) in the Flyte v2 executor was assigning the object name using taskCtx.GetTaskExecutionID().GetGeneratedName() directly without checking or applying GeneratedNameMaxLength.

This PR modifies the plugin manager to check GeneratedNameMaxLength and call GetGeneratedNameWith instead, ensuring that generated resource names are properly bounded and truncated within the limits of the target plugin.

What changes were proposed in this pull request?

This PR updates the Kubernetes plugin metadata builder to respect the name length limits specified by plugins:

• Respect GeneratedNameMaxLength : In plugin_manager.go, updated the addObjectMetadata function to inspect pm.plugin.GetProperties().GeneratedNameMaxLength.
• Bounded Name Generation: If a maximum length limit is specified by the plugin properties, the manager now invokes GetGeneratedNameWith(0, maxLength)
  instead of GetGeneratedName() to securely bound and truncate the resource name.
• Compatibility Safety: Bounding the name prior to running validation.IsDNS1123Subdomain ensures that trailing hyphens or dot separators resulting from truncation are automatically cleaned up.

How was this patch tested?

1. Unit Tests:
   Ran the test suites for the executor plugin package and the Ray task plugin package to ensure that there are no regressions:
   Run executor plugin tests
   go test -v ./pkg/plugin/...

   Run Ray plugin tests
   go test -v ./go/tasks/plugins/k8s/ray/...

2. Compilation:
   Verified that both the manager and executor entry points compile successfully:
   go build ./executor/cmd/main.go
go build ./manager/cmd/main.go

Labels

• fixed

Setup process

Screenshots

Check all the applicable boxes

• I updated the documentation accordingly.
• All new and existing tests passed.
• All commits are signed-off.

Related PRs

Stack

If you do use git town to manage PR Stacks, the stack relevant to this PR
will show below. Otherwise, you can ignore this section.

Docs link