workloadmonitor: bucket Workloads carry the bucket- prefix twice #5014

Problem / motivation

Workload objects created for S3 buckets carry the bucket- prefix twice, so a bucket an operator knows as cozy-backups appears in billing output as bucket-bucket-cozy-backups.

The Workload name is built by prefixing the BucketClaim name:

// internal/controller/workloadmonitor_controller.go:600
Name: fmt.Sprintf("bucket-%s", bc.Name),

and the BucketClaim is named after the Helm release:

# packages/apps/bucket/templates/bucketclaim.yaml
kind: BucketClaim
metadata:
  name: {{ .Release.Name }}

For a Bucket application the release name already starts with bucket-, so the two stack. On a live cluster:

BucketClaim   bucket-cozy-backups
Workload      bucket-bucket-cozy-backups

Pods, PVCs and services do not have this: their Workloads are named after an object whose name does not already carry the kind.

This is cosmetic in the sense that nothing malfunctions, but the name is not internal. It is the workload field of every consumer in a billing usage report, so it reaches whoever reads the bill, and it was noticed by an operator reading one.

Proposed solution

Stop prefixing when the source name already carries it, or drop the prefix for this kind and name the Workload after the claim directly.

Either way the rename is not free: Workload names are the identity billing integrates over, and existing objects would be replaced rather than renamed in place. A consumer whose name changes mid-period shows up as two consumers in a report that spans the change. That is worth saying out loud in the change, and it argues for doing it in a release where that is acceptable rather than a patch.

Scope check

• This affects a single component / package (if it spans many, consider a design proposal)
• I can describe the expected behavior concretely (if not, consider a Discussion first)

Alternatives considered

Leave it and document it. Defensible, since nothing breaks, but the string is read by people who did not choose it and have no way to know why it doubles.

Rename in the bucket chart instead, so the BucketClaim is not named after the release. That moves the collision rather than removing it, and the claim name is referenced by BucketAccess objects in the same chart.

Additional context

• internal/controller/workloadmonitor_controller.go:600 builds the name
• packages/apps/bucket/templates/bucketclaim.yaml names the claim after the release