Prefixing Helm release name in linkerd K8S object names

[sysarch-repo]

I am using a proprietary Helm framework that prefixes the release name to the K8S object names (deployments, pods, services...). These are basically best practices as I know them. But when applying this concept to linkerd then the identity pod will not start and throws an error:

ubuntu@domainmgr1:~/helm/nti-mesh$ kubectl get pods -n nti-mesh
NAME                                   READY   STATUS    RESTARTS   AGE
nsmc-controller-cd74858d9-4n2pq        0/2     Running   0          44s
nsmc-destination-9957c4d5f-b8kdx       0/2     Running   0          44s
nsmc-identity-7d56db7bd8-t7vwr         0/2     Error     0          44s
nsmc-proxy-injector-7cb4cb9d47-9qbkl   0/2     Running   0          44s
nsmc-sp-validator-6f984689bd-fklzh     0/2     Running   0          44s

ubuntu@domainmgr1:~/helm/nti-mesh$ kubectl logs -n nti-mesh nsmc-identity-7d56db7bd8-t7vwr -c identity
Linkerd readiness check skipped: linkerd-await cannot block the identity controller
time="2021-09-07T00:31:48Z" level=info msg="running version stable-2.10.2"
time="2021-09-07T00:31:48Z" level=fatal msg="Failed to construct k8s event recorder: deployments.apps \"linkerd-identity\" not found"

It seems the identity pod hardcodes its own deployment name to "linkerd-identity" while in my deployment this name shall be "nsmc-identity". Is there a parameter that controls this behavior or must the release name always be "linkerd"? I confirm that using "linkerd" as the release name (that gets prefixed to the K8S object names) makes the linkerd components start and run as expected.

BTW I have no issues using linkerd as the release name that is anyway needed for example to make the linkerd CLI client functioning correctly. I am just curious whether this behavior is intentional or rather unexpected.

[alpeb]

That deployment name is indeed hard-coded into the identity code. There could be other instances in other places where a similar problem occurs, but this is the first time to my knowledge that this causes an issue for someone. It shouldn't be a big deal to amend though, so we'd be glad to guide anyone wanting to put some time into having this work on labels instead of resource names 😉

[sysarch-repo]

Thanks, @alpeb, for confirming the implemented behavior!