add option for namespace in values instead of Release.Namespace

[ac427]

---

feat: Add configurable namespace support to Helm chart

Problem

All chart resources were hardcoded to use {{ .Release.Namespace }}, which forced Trident to be installed into whichever namespace Helm was deployed to. There was no way to deploy the operator in one namespace while running Trident in another, and the pre-delete hook scripts had the namespace literally hardcoded as trident.

Solution

Introduced a namespace value that, when set, overrides the Helm release namespace across all chart resources. A single trident.namespace helper centralizes the resolution logic so there is only one place to change if the behavior needs to evolve.

Changes

values.yaml

• Added namespace: "" — leave empty to use Helm release namespace (default/backward-compatible behavior)

templates/_helpers.tpl

• Added trident.namespace helper: resolves Values.namespace if set, falls back to Release.Namespace
• Updated shouldInstallRancherRoles to use the helper instead of Release.Namespace directly

Templates updated to use {{ include "trident.namespace" . }}:

• deployment.yaml
• serviceaccount.yaml
• clusterrolebinding.yaml
• clusterrolebinding-rancher.yaml
• tridentorchestrator.yaml
• postinstallupgradehook.yaml
• postdeletecrdshook.yaml
• predeletecrdshook.yaml — including the kubectl commands that previously hardcoded -n trident
• NOTES.txt

Backward Compatibility

• ✅ No breaking change — leaving namespace empty preserves existing behavior
• ✅ Existing deployments upgrading without setting namespace are unaffected

Usage

# Deploy operator and Trident into a custom namespace
helm install trident-operator ./trident-operator --set namespace=my-trident-ns

# Default behavior (unchanged)
helm install trident-operator ./trident-operator -n trident

Also Included

• Fixed UPGRADE FAILED: no matches for kind "TridentOrchestrator" by adding post-install,post-upgrade hook annotations to TridentOrchestrator and TridentConfigurator resources, ensuring CRDs are registered before custom resources are applied