When mounting scratch area as a PVC, blueapi cannot support multiple instances in a namespace

[DiamondJoseph]

Because the PV[C] (PersistentVolume[Claim]) that is created is named (pseudo-code) scratch-{version}, when multiple blueapis of the same version are in a namespace, they cannot each create unique PV[C]s, leaving one is left unable to start.

Recommended solution: Append the name of the Release (which is already enforced to be unique in the namespace) to the name of the Volume and where it is mounted:

blueapi/helm/blueapi/templates/volumes.yaml

Line 5 in c623987

name: scratch-{{ .Values.image.tag | default .Chart.AppVersion }}

blueapi/helm/blueapi/templates/statefulset.yaml

Line 63 in c623987

claimName: {{default (tpl "scratch-{{ .Values.image.tag | default .Chart.AppVersion }}" .) .Values.initContainer.persistentVolume.existingClaimName }}

An example of this is found here- this uses the fullname helper method, which is defined for charts by default:

blueapi/helm/blueapi/templates/_helpers.tpl

Line 8 in c623987

{{/*

Alternatively, we could construct a unique name from fields of the the .Chart or .Release globals directly, as the fullname does.

The fullname helper is already used to define all other namespace resources,
e.g.:

blueapi/helm/blueapi/templates/configmap.yaml

Line 4 in c623987

name: {{ include "blueapi.fullname" . }}-config

blueapi/helm/blueapi/templates/statefulset.yaml

Line 4 in c623987

name: {{ include "blueapi.fullname" . }}

Steps To Reproduce

Steps to reproduce the behavior:

1. Check i15-beamline namespace in k8s-i15 cluster

Acceptance Criteria

• When multiple blueapi instances are created with a scratch area in a PVC, they are all able to start