fix: conditional aws-hyperpod namespace creation

[GusAntoniassi]

What's changing and why?

Our aws-hyperpod namespace has been created by our internal machinery, to add special permissions and guardrails. Currently, when trying to apply the Helm chart, we have the following error:

Error: Unable to continue with install: Namespace "aws-hyperpod" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "hyperpod-dependencies"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "kube-system"`

We've tried setting namespace.create in values.yaml, but that did not work. Upon further investigation, I saw that the aws-hyperpod-namespace.yaml template was not using these variables at all.

Before/After UX

Before:

# values.yamlnamespace:
name: "aws-hyperpod"create: true

These values were not being used by any subchart, and updating them did not change anything.

After:

deep-health-check:
enabled: truenamespace:
create: truename: aws-hyperpod

These values now govern the creation of the aws-hyperpod namespace.

How was this change tested?

Changes were tested using the helm template command, to validate both current behavior (aws-hyperpod being created by default), and new behavior (flag --set deep-health-check.namespace.create=false disables the aws-hyperpod namespace template).

Are unit tests added?

Not necessary

Are integration tests added?

Not necessary

Reviewer Guidelines

‼️Merge Requirements: PRs with failing integration tests cannot be merged without justification.

One of the following must be true:

• All automated PR checks pass
• Failed tests include local run results/screenshots proving they work
• Changes are documentation-only

[mufaddal-rohawala]

Thanks for the fix, @GusAntoniassi — the root-cause diagnosis is correct. The top-level namespace block in the parent values.yaml was genuinely dead config, and the deep-health-check RBAC template was already misusing .Values.namespace as a string, so wiring these up is the right call. A few things to address before merge (inline comments):

1. {{- end }} placement in mpi-operator/templates/rbac.yaml
2. Missing trailing newline in aws-hyperpod-namespace.yaml
3. Trailing whitespace in the parent values.yaml

Could you also attach helm template output with deep-health-check.namespace.create set to both true and false so we can confirm the rendered manifests are valid in both states?

[GusAntoniassi]

Thanks for your review @mufaddal-rohawala. I've addressed these changes in the latest commit.

I'm attaching only the deep-health-check templates, let me know if you need the full helm render output too.

deep-health-check.namespace.create=false:

---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlapiVersion: v1kind: ServiceAccountmetadata:
name: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-rolerules:
- apiGroups:
- ""resources:
- nodesverbs:
- get
- list
- apiGroups:
- ""resources:
- podsverbs:
- get
- list
- patch
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-role-bindingroleRef:
apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: deep-health-check-service-account-rolesubjects:
- kind: ServiceAccountname: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yaml# rbac.yaml# service account

deep-health-check.namespace.create=true:

---
# Source: deep-health-check/templates/aws-hyperpod-namespace.yamlapiVersion: v1kind: Namespacemetadata:
name: aws-hyperpodlabels:
name: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlapiVersion: v1kind: ServiceAccountmetadata:
name: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-rolerules:
- apiGroups:
- ""resources:
- nodesverbs:
- get
- list
- apiGroups:
- ""resources:
- podsverbs:
- get
- list
- patch
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-role-bindingroleRef:
apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: deep-health-check-service-account-rolesubjects:
- kind: ServiceAccountname: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yaml# rbac.yaml# service account

[piyushdaftary]

@mufaddal-rohawala@mujtaba1747 : Can you please help to review and merge the PR ?

[GusAntoniassi]

What's changing and why?

Our aws-hyperpod namespace has been created by our internal machinery, to add special permissions and guardrails. Currently, when trying to apply the Helm chart, we have the following error:

Error: Unable to continue with install: Namespace "aws-hyperpod" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "hyperpod-dependencies"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "kube-system"`

We've tried setting namespace.create in values.yaml, but that did not work. Upon further investigation, I saw that the aws-hyperpod-namespace.yaml template was not using these variables at all.

Before/After UX

Before:

# values.yamlnamespace:
name: "aws-hyperpod"create: true

These values were not being used by any subchart, and updating them did not change anything.

After:

deep-health-check:
enabled: truenamespace:
create: truename: aws-hyperpod

These values now govern the creation of the aws-hyperpod namespace.

How was this change tested?

Changes were tested using the helm template command, to validate both current behavior (aws-hyperpod being created by default), and new behavior (flag --set deep-health-check.namespace.create=false disables the aws-hyperpod namespace template).

Are unit tests added?

Not necessary

Are integration tests added?

Not necessary

Reviewer Guidelines

‼️Merge Requirements: PRs with failing integration tests cannot be merged without justification.

One of the following must be true:

• All automated PR checks pass
• Failed tests include local run results/screenshots proving they work
• Changes are documentation-only

[mufaddal-rohawala]

Thanks for the fix, @GusAntoniassi — the root-cause diagnosis is correct. The top-level namespace block in the parent values.yaml was genuinely dead config, and the deep-health-check RBAC template was already misusing .Values.namespace as a string, so wiring these up is the right call. A few things to address before merge (inline comments):

1. {{- end }} placement in mpi-operator/templates/rbac.yaml
2. Missing trailing newline in aws-hyperpod-namespace.yaml
3. Trailing whitespace in the parent values.yaml

Could you also attach helm template output with deep-health-check.namespace.create set to both true and false so we can confirm the rendered manifests are valid in both states?

[GusAntoniassi]

Thanks for your review @mufaddal-rohawala. I've addressed these changes in the latest commit.

I'm attaching only the deep-health-check templates, let me know if you need the full helm render output too.

deep-health-check.namespace.create=false:

---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlapiVersion: v1kind: ServiceAccountmetadata:
name: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-rolerules:
- apiGroups:
- ""resources:
- nodesverbs:
- get
- list
- apiGroups:
- ""resources:
- podsverbs:
- get
- list
- patch
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-role-bindingroleRef:
apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: deep-health-check-service-account-rolesubjects:
- kind: ServiceAccountname: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yaml# rbac.yaml# service account

deep-health-check.namespace.create=true:

---
# Source: deep-health-check/templates/aws-hyperpod-namespace.yamlapiVersion: v1kind: Namespacemetadata:
name: aws-hyperpodlabels:
name: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlapiVersion: v1kind: ServiceAccountmetadata:
name: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-rolerules:
- apiGroups:
- ""resources:
- nodesverbs:
- get
- list
- apiGroups:
- ""resources:
- podsverbs:
- get
- list
- patch
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-role-bindingroleRef:
apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: deep-health-check-service-account-rolesubjects:
- kind: ServiceAccountname: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yaml# rbac.yaml# service account

[piyushdaftary]

@mufaddal-rohawala@mujtaba1747 : Can you please help to review and merge the PR ?

[GusAntoniassi]

What's changing and why?

Our aws-hyperpod namespace has been created by our internal machinery, to add special permissions and guardrails. Currently, when trying to apply the Helm chart, we have the following error:

Error: Unable to continue with install: Namespace "aws-hyperpod" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "hyperpod-dependencies"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "kube-system"`

We've tried setting namespace.create in values.yaml, but that did not work. Upon further investigation, I saw that the aws-hyperpod-namespace.yaml template was not using these variables at all.

Before/After UX

Before:

# values.yamlnamespace:
name: "aws-hyperpod"create: true

These values were not being used by any subchart, and updating them did not change anything.

After:

deep-health-check:
enabled: truenamespace:
create: truename: aws-hyperpod

These values now govern the creation of the aws-hyperpod namespace.

How was this change tested?

Changes were tested using the helm template command, to validate both current behavior (aws-hyperpod being created by default), and new behavior (flag --set deep-health-check.namespace.create=false disables the aws-hyperpod namespace template).

Are unit tests added?

Not necessary

Are integration tests added?

Not necessary

Reviewer Guidelines

‼️Merge Requirements: PRs with failing integration tests cannot be merged without justification.

One of the following must be true:

• All automated PR checks pass
• Failed tests include local run results/screenshots proving they work
• Changes are documentation-only

[mufaddal-rohawala]

Thanks for the fix, @GusAntoniassi — the root-cause diagnosis is correct. The top-level namespace block in the parent values.yaml was genuinely dead config, and the deep-health-check RBAC template was already misusing .Values.namespace as a string, so wiring these up is the right call. A few things to address before merge (inline comments):

1. {{- end }} placement in mpi-operator/templates/rbac.yaml
2. Missing trailing newline in aws-hyperpod-namespace.yaml
3. Trailing whitespace in the parent values.yaml

Could you also attach helm template output with deep-health-check.namespace.create set to both true and false so we can confirm the rendered manifests are valid in both states?

[GusAntoniassi]

Thanks for your review @mufaddal-rohawala. I've addressed these changes in the latest commit.

I'm attaching only the deep-health-check templates, let me know if you need the full helm render output too.

deep-health-check.namespace.create=false:

---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlapiVersion: v1kind: ServiceAccountmetadata:
name: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-rolerules:
- apiGroups:
- ""resources:
- nodesverbs:
- get
- list
- apiGroups:
- ""resources:
- podsverbs:
- get
- list
- patch
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-role-bindingroleRef:
apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: deep-health-check-service-account-rolesubjects:
- kind: ServiceAccountname: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yaml# rbac.yaml# service account

deep-health-check.namespace.create=true:

---
# Source: deep-health-check/templates/aws-hyperpod-namespace.yamlapiVersion: v1kind: Namespacemetadata:
name: aws-hyperpodlabels:
name: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlapiVersion: v1kind: ServiceAccountmetadata:
name: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-rolerules:
- apiGroups:
- ""resources:
- nodesverbs:
- get
- list
- apiGroups:
- ""resources:
- podsverbs:
- get
- list
- patch
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-role-bindingroleRef:
apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: deep-health-check-service-account-rolesubjects:
- kind: ServiceAccountname: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yaml# rbac.yaml# service account

[piyushdaftary]

@mufaddal-rohawala@mujtaba1747 : Can you please help to review and merge the PR ?

[GusAntoniassi]

What's changing and why?

Our aws-hyperpod namespace has been created by our internal machinery, to add special permissions and guardrails. Currently, when trying to apply the Helm chart, we have the following error:

Error: Unable to continue with install: Namespace "aws-hyperpod" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "hyperpod-dependencies"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "kube-system"`

We've tried setting namespace.create in values.yaml, but that did not work. Upon further investigation, I saw that the aws-hyperpod-namespace.yaml template was not using these variables at all.

Before/After UX

Before:

# values.yamlnamespace:
name: "aws-hyperpod"create: true

These values were not being used by any subchart, and updating them did not change anything.

After:

deep-health-check:
enabled: truenamespace:
create: truename: aws-hyperpod

These values now govern the creation of the aws-hyperpod namespace.

How was this change tested?

Changes were tested using the helm template command, to validate both current behavior (aws-hyperpod being created by default), and new behavior (flag --set deep-health-check.namespace.create=false disables the aws-hyperpod namespace template).

Are unit tests added?

Not necessary

Are integration tests added?

Not necessary

Reviewer Guidelines

‼️Merge Requirements: PRs with failing integration tests cannot be merged without justification.

One of the following must be true:

• All automated PR checks pass
• Failed tests include local run results/screenshots proving they work
• Changes are documentation-only

[mufaddal-rohawala]

Thanks for the fix, @GusAntoniassi — the root-cause diagnosis is correct. The top-level namespace block in the parent values.yaml was genuinely dead config, and the deep-health-check RBAC template was already misusing .Values.namespace as a string, so wiring these up is the right call. A few things to address before merge (inline comments):

1. {{- end }} placement in mpi-operator/templates/rbac.yaml
2. Missing trailing newline in aws-hyperpod-namespace.yaml
3. Trailing whitespace in the parent values.yaml

Could you also attach helm template output with deep-health-check.namespace.create set to both true and false so we can confirm the rendered manifests are valid in both states?

[GusAntoniassi]

Thanks for your review @mufaddal-rohawala. I've addressed these changes in the latest commit.

I'm attaching only the deep-health-check templates, let me know if you need the full helm render output too.

deep-health-check.namespace.create=false:

---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlapiVersion: v1kind: ServiceAccountmetadata:
name: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-rolerules:
- apiGroups:
- ""resources:
- nodesverbs:
- get
- list
- apiGroups:
- ""resources:
- podsverbs:
- get
- list
- patch
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-role-bindingroleRef:
apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: deep-health-check-service-account-rolesubjects:
- kind: ServiceAccountname: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yaml# rbac.yaml# service account

deep-health-check.namespace.create=true:

---
# Source: deep-health-check/templates/aws-hyperpod-namespace.yamlapiVersion: v1kind: Namespacemetadata:
name: aws-hyperpodlabels:
name: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlapiVersion: v1kind: ServiceAccountmetadata:
name: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-rolerules:
- apiGroups:
- ""resources:
- nodesverbs:
- get
- list
- apiGroups:
- ""resources:
- podsverbs:
- get
- list
- patch
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-role-bindingroleRef:
apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: deep-health-check-service-account-rolesubjects:
- kind: ServiceAccountname: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yaml# rbac.yaml# service account

[piyushdaftary]

@mufaddal-rohawala@mujtaba1747 : Can you please help to review and merge the PR ?

[GusAntoniassi]

What's changing and why?

Our aws-hyperpod namespace has been created by our internal machinery, to add special permissions and guardrails. Currently, when trying to apply the Helm chart, we have the following error:

Error: Unable to continue with install: Namespace "aws-hyperpod" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "hyperpod-dependencies"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "kube-system"`

We've tried setting namespace.create in values.yaml, but that did not work. Upon further investigation, I saw that the aws-hyperpod-namespace.yaml template was not using these variables at all.

Before/After UX

Before:

# values.yamlnamespace:
name: "aws-hyperpod"create: true

These values were not being used by any subchart, and updating them did not change anything.

After:

deep-health-check:
enabled: truenamespace:
create: truename: aws-hyperpod

These values now govern the creation of the aws-hyperpod namespace.

How was this change tested?

Changes were tested using the helm template command, to validate both current behavior (aws-hyperpod being created by default), and new behavior (flag --set deep-health-check.namespace.create=false disables the aws-hyperpod namespace template).

Are unit tests added?

Not necessary

Are integration tests added?

Not necessary

Reviewer Guidelines

‼️Merge Requirements: PRs with failing integration tests cannot be merged without justification.

One of the following must be true:

• All automated PR checks pass
• Failed tests include local run results/screenshots proving they work
• Changes are documentation-only

[mufaddal-rohawala]

Thanks for the fix, @GusAntoniassi — the root-cause diagnosis is correct. The top-level namespace block in the parent values.yaml was genuinely dead config, and the deep-health-check RBAC template was already misusing .Values.namespace as a string, so wiring these up is the right call. A few things to address before merge (inline comments):

1. {{- end }} placement in mpi-operator/templates/rbac.yaml
2. Missing trailing newline in aws-hyperpod-namespace.yaml
3. Trailing whitespace in the parent values.yaml

Could you also attach helm template output with deep-health-check.namespace.create set to both true and false so we can confirm the rendered manifests are valid in both states?

[GusAntoniassi]

Thanks for your review @mufaddal-rohawala. I've addressed these changes in the latest commit.

I'm attaching only the deep-health-check templates, let me know if you need the full helm render output too.

deep-health-check.namespace.create=false:

---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlapiVersion: v1kind: ServiceAccountmetadata:
name: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-rolerules:
- apiGroups:
- ""resources:
- nodesverbs:
- get
- list
- apiGroups:
- ""resources:
- podsverbs:
- get
- list
- patch
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-role-bindingroleRef:
apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: deep-health-check-service-account-rolesubjects:
- kind: ServiceAccountname: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yaml# rbac.yaml# service account

deep-health-check.namespace.create=true:

---
# Source: deep-health-check/templates/aws-hyperpod-namespace.yamlapiVersion: v1kind: Namespacemetadata:
name: aws-hyperpodlabels:
name: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlapiVersion: v1kind: ServiceAccountmetadata:
name: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-rolerules:
- apiGroups:
- ""resources:
- nodesverbs:
- get
- list
- apiGroups:
- ""resources:
- podsverbs:
- get
- list
- patch
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-role-bindingroleRef:
apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: deep-health-check-service-account-rolesubjects:
- kind: ServiceAccountname: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yaml# rbac.yaml# service account

[piyushdaftary]

@mufaddal-rohawala@mujtaba1747 : Can you please help to review and merge the PR ?

[GusAntoniassi]

What's changing and why?

Our aws-hyperpod namespace has been created by our internal machinery, to add special permissions and guardrails. Currently, when trying to apply the Helm chart, we have the following error:

Error: Unable to continue with install: Namespace "aws-hyperpod" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "hyperpod-dependencies"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "kube-system"`

We've tried setting namespace.create in values.yaml, but that did not work. Upon further investigation, I saw that the aws-hyperpod-namespace.yaml template was not using these variables at all.

Before/After UX

Before:

# values.yamlnamespace:
name: "aws-hyperpod"create: true

These values were not being used by any subchart, and updating them did not change anything.

After:

deep-health-check:
enabled: truenamespace:
create: truename: aws-hyperpod

These values now govern the creation of the aws-hyperpod namespace.

How was this change tested?

Changes were tested using the helm template command, to validate both current behavior (aws-hyperpod being created by default), and new behavior (flag --set deep-health-check.namespace.create=false disables the aws-hyperpod namespace template).

Are unit tests added?

Not necessary

Are integration tests added?

Not necessary

Reviewer Guidelines

‼️Merge Requirements: PRs with failing integration tests cannot be merged without justification.

One of the following must be true:

• All automated PR checks pass
• Failed tests include local run results/screenshots proving they work
• Changes are documentation-only

[mufaddal-rohawala]

Thanks for the fix, @GusAntoniassi — the root-cause diagnosis is correct. The top-level namespace block in the parent values.yaml was genuinely dead config, and the deep-health-check RBAC template was already misusing .Values.namespace as a string, so wiring these up is the right call. A few things to address before merge (inline comments):

1. {{- end }} placement in mpi-operator/templates/rbac.yaml
2. Missing trailing newline in aws-hyperpod-namespace.yaml
3. Trailing whitespace in the parent values.yaml

Could you also attach helm template output with deep-health-check.namespace.create set to both true and false so we can confirm the rendered manifests are valid in both states?

[GusAntoniassi]

Thanks for your review @mufaddal-rohawala. I've addressed these changes in the latest commit.

I'm attaching only the deep-health-check templates, let me know if you need the full helm render output too.

deep-health-check.namespace.create=false:

---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlapiVersion: v1kind: ServiceAccountmetadata:
name: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-rolerules:
- apiGroups:
- ""resources:
- nodesverbs:
- get
- list
- apiGroups:
- ""resources:
- podsverbs:
- get
- list
- patch
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-role-bindingroleRef:
apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: deep-health-check-service-account-rolesubjects:
- kind: ServiceAccountname: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yaml# rbac.yaml# service account

deep-health-check.namespace.create=true:

---
# Source: deep-health-check/templates/aws-hyperpod-namespace.yamlapiVersion: v1kind: Namespacemetadata:
name: aws-hyperpodlabels:
name: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlapiVersion: v1kind: ServiceAccountmetadata:
name: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-rolerules:
- apiGroups:
- ""resources:
- nodesverbs:
- get
- list
- apiGroups:
- ""resources:
- podsverbs:
- get
- list
- patch
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-role-bindingroleRef:
apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: deep-health-check-service-account-rolesubjects:
- kind: ServiceAccountname: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yaml# rbac.yaml# service account

[piyushdaftary]

@mufaddal-rohawala@mujtaba1747 : Can you please help to review and merge the PR ?

[GusAntoniassi]

What's changing and why?

Our aws-hyperpod namespace has been created by our internal machinery, to add special permissions and guardrails. Currently, when trying to apply the Helm chart, we have the following error:

Error: Unable to continue with install: Namespace "aws-hyperpod" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "hyperpod-dependencies"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "kube-system"`

We've tried setting namespace.create in values.yaml, but that did not work. Upon further investigation, I saw that the aws-hyperpod-namespace.yaml template was not using these variables at all.

Before/After UX

Before:

# values.yamlnamespace:
name: "aws-hyperpod"create: true

These values were not being used by any subchart, and updating them did not change anything.

After:

deep-health-check:
enabled: truenamespace:
create: truename: aws-hyperpod

These values now govern the creation of the aws-hyperpod namespace.

How was this change tested?

Changes were tested using the helm template command, to validate both current behavior (aws-hyperpod being created by default), and new behavior (flag --set deep-health-check.namespace.create=false disables the aws-hyperpod namespace template).

Are unit tests added?

Not necessary

Are integration tests added?

Not necessary

Reviewer Guidelines

‼️Merge Requirements: PRs with failing integration tests cannot be merged without justification.

One of the following must be true:

• All automated PR checks pass
• Failed tests include local run results/screenshots proving they work
• Changes are documentation-only

[mufaddal-rohawala]

Thanks for the fix, @GusAntoniassi — the root-cause diagnosis is correct. The top-level namespace block in the parent values.yaml was genuinely dead config, and the deep-health-check RBAC template was already misusing .Values.namespace as a string, so wiring these up is the right call. A few things to address before merge (inline comments):

1. {{- end }} placement in mpi-operator/templates/rbac.yaml
2. Missing trailing newline in aws-hyperpod-namespace.yaml
3. Trailing whitespace in the parent values.yaml

Could you also attach helm template output with deep-health-check.namespace.create set to both true and false so we can confirm the rendered manifests are valid in both states?

[GusAntoniassi]

Thanks for your review @mufaddal-rohawala. I've addressed these changes in the latest commit.

I'm attaching only the deep-health-check templates, let me know if you need the full helm render output too.

deep-health-check.namespace.create=false:

---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlapiVersion: v1kind: ServiceAccountmetadata:
name: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-rolerules:
- apiGroups:
- ""resources:
- nodesverbs:
- get
- list
- apiGroups:
- ""resources:
- podsverbs:
- get
- list
- patch
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-role-bindingroleRef:
apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: deep-health-check-service-account-rolesubjects:
- kind: ServiceAccountname: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yaml# rbac.yaml# service account

deep-health-check.namespace.create=true:

---
# Source: deep-health-check/templates/aws-hyperpod-namespace.yamlapiVersion: v1kind: Namespacemetadata:
name: aws-hyperpodlabels:
name: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlapiVersion: v1kind: ServiceAccountmetadata:
name: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-rolerules:
- apiGroups:
- ""resources:
- nodesverbs:
- get
- list
- apiGroups:
- ""resources:
- podsverbs:
- get
- list
- patch
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-role-bindingroleRef:
apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: deep-health-check-service-account-rolesubjects:
- kind: ServiceAccountname: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yaml# rbac.yaml# service account

[piyushdaftary]

@mufaddal-rohawala@mujtaba1747 : Can you please help to review and merge the PR ?

[GusAntoniassi]

What's changing and why?

Our aws-hyperpod namespace has been created by our internal machinery, to add special permissions and guardrails. Currently, when trying to apply the Helm chart, we have the following error:

Error: Unable to continue with install: Namespace "aws-hyperpod" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "hyperpod-dependencies"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "kube-system"`

We've tried setting namespace.create in values.yaml, but that did not work. Upon further investigation, I saw that the aws-hyperpod-namespace.yaml template was not using these variables at all.

Before/After UX

Before:

# values.yamlnamespace:
name: "aws-hyperpod"create: true

These values were not being used by any subchart, and updating them did not change anything.

After:

deep-health-check:
enabled: truenamespace:
create: truename: aws-hyperpod

These values now govern the creation of the aws-hyperpod namespace.

How was this change tested?

Changes were tested using the helm template command, to validate both current behavior (aws-hyperpod being created by default), and new behavior (flag --set deep-health-check.namespace.create=false disables the aws-hyperpod namespace template).

Are unit tests added?

Not necessary

Are integration tests added?

Not necessary

Reviewer Guidelines

‼️Merge Requirements: PRs with failing integration tests cannot be merged without justification.

One of the following must be true:

• All automated PR checks pass
• Failed tests include local run results/screenshots proving they work
• Changes are documentation-only

[mufaddal-rohawala]

Thanks for the fix, @GusAntoniassi — the root-cause diagnosis is correct. The top-level namespace block in the parent values.yaml was genuinely dead config, and the deep-health-check RBAC template was already misusing .Values.namespace as a string, so wiring these up is the right call. A few things to address before merge (inline comments):

1. {{- end }} placement in mpi-operator/templates/rbac.yaml
2. Missing trailing newline in aws-hyperpod-namespace.yaml
3. Trailing whitespace in the parent values.yaml

Could you also attach helm template output with deep-health-check.namespace.create set to both true and false so we can confirm the rendered manifests are valid in both states?

[GusAntoniassi]

Thanks for your review @mufaddal-rohawala. I've addressed these changes in the latest commit.

I'm attaching only the deep-health-check templates, let me know if you need the full helm render output too.

deep-health-check.namespace.create=false:

---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlapiVersion: v1kind: ServiceAccountmetadata:
name: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-rolerules:
- apiGroups:
- ""resources:
- nodesverbs:
- get
- list
- apiGroups:
- ""resources:
- podsverbs:
- get
- list
- patch
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-role-bindingroleRef:
apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: deep-health-check-service-account-rolesubjects:
- kind: ServiceAccountname: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yaml# rbac.yaml# service account

deep-health-check.namespace.create=true:

---
# Source: deep-health-check/templates/aws-hyperpod-namespace.yamlapiVersion: v1kind: Namespacemetadata:
name: aws-hyperpodlabels:
name: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlapiVersion: v1kind: ServiceAccountmetadata:
name: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-rolerules:
- apiGroups:
- ""resources:
- nodesverbs:
- get
- list
- apiGroups:
- ""resources:
- podsverbs:
- get
- list
- patch
---
# Source: deep-health-check/templates/deep-health-check-rbac.yamlkind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata:
name: deep-health-check-service-account-role-bindingroleRef:
apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: deep-health-check-service-account-rolesubjects:
- kind: ServiceAccountname: deep-health-check-service-accountnamespace: aws-hyperpod
---
# Source: deep-health-check/templates/deep-health-check-rbac.yaml# rbac.yaml# service account

[piyushdaftary]

@mufaddal-rohawala@mujtaba1747 : Can you please help to review and merge the PR ?