feat: introduce namespaceOverride

[khaledCNTXT]

Motivation

Extended the Helm chart to allow for a namespace override via the new namespaceOverride value. This ensures that a custom namespace can be specified and used, otherwise defaults to the release namespace. This update enhances deployment flexibility in different Kubernetes environments.

Changes

add namespaceOverride to Values

[alexrashed]

Hi @khaledCNTXT!
Thanks a lot for your contribution! Could you please elaborate a bit on why you would like to use a different namespace than the release namespace here?
You could just define the release namespace when installing the chart:

helm install localstack localstack/localstack -n this-is-my-custom-namespace --create-namespace

[khaledCNTXT]

Hi @alexrashed
We are using Novu Helm, which relies on LocalStack as a dependency. Therefore, we need to install all the resources under the novu namespace. Additionally, we have other resources that need to be deployed to a different namespace.

[alexrashed]

Interesting. Helm would use the same namespace for dependencies as well, so why wouldn't LocalStack as a dependency of the chart you mentioned not be installed in the same? Maybe the chart you mean has some special namespace handling?
Could you maybe give us a minimum-reproducible-sample showcasing your issue?

[khaledCNTXT]

We have a Helm chart with multiple dependencies as follows:

apiVersion: v2
name: XXXXX
description: XXXXX
version: 0.1.0

dependencies:
  - name: cloudSqlProxy
    version: 1.0.0
    repository: "file://services/cloudSqlProxy"
    condition: cloudSqlProxy.enabled

  - name: cert-manager
    version: v1.15.1
    repository: https://charts.jetstack.io
    condition: cert-manager.enabled

  - name: novu
    repository: "git+https://github.com/novuhq/community-k8s@helm"
    version: "*"
    condition: novu.enabled

Key Points:

1. Namespace Deployment:
   Each dependency (cloudSqlProxy, cert-manager, novu) needs to be deployed in its own namespace.

2. Novu Sub-dependencies:
   Novu has additional dependencies such as localstack. These also need to be deployed in their own separate namespaces.

3. Values File:
   We're using a single values file to manage configurations for all dependencies.
   This values file contains a section for localstack, and we need to ensure the correct namespace is passed from this section for localstack.

[alexrashed]

Interesting, thanks a lot for the explanation. I can see that this can be useful, and it seems to be a somewhat-best-practice used in multiple charts. In fact, there's a utility function in bitnami/common (implemented in bitnami/charts#9396), which we already have as a dependency. It's also the same utility used in the novu chart here.

I would suggest to modify your PR such that:

• It does not define a new function, but uses the function in bitnami/commons.
• Set the namespace accordingly in all templates (not only in the deployment).

What do you think?

[khaledCNTXT]

sure i will update the PR

[khaledCNTXT]

I reviewed the documentation at
https://github.com/novuhq/community-k8s/tree/fb860df320ee6b47cc109355aa1e117b16cc5d1b/helm
and it appears that common.names.namespace is not a valid option for us to use. Is there something I might be missing

[alexrashed]

I reviewed the documentation at
https://github.com/novuhq/community-k8s/tree/fb860df320ee6b47cc109355aa1e117b16cc5d1b/helm
and it appears that common.names.namespace is not a valid option for us to use. Is there something I might be missing

I am not sure what you mean by that to be honest. We - same as the novu chart - both have the bitnami commons chart in our dependencies. Novu already uses the common.names.namespace in their chart (as linked above). We could do the exact same thing (see the suggested change in the comment).

Does that answer your question?

[alexrashed]

There's a bit of a misunderstanding. I tried to explain that in the comments, but imho you should be able to just remove the two sections I commented on, and it should work just fine with the value you initially proposed (namespaceOverride).
Would you mind giving this a try? Do you have any questions on that? :)

[alexrashed]

If we can use common.names.namespaces from the subchart, this isn't necessary:

Suggested change

	common:
	names:
	namespaces: ""

[alexrashed]

Sorry it took a while to pick this PR up again, it slipped through because you didn't re-request a review (see step 5 in this GitHub doc).
The chagnes are looking good, but there are still two templates that do not use the new way to determine the namespace to deploy the resource in:

• charts/localstack/templates/tests/test-connection.yaml (line 6)
• charts/localstack/templates/tests/test-s3.yaml (line 6)

If you change these two lines, we are good to go! I already tested this locally on my machine.
If you want, I can also take this PR over, but right now I am not allowed to push changes to your PR.

[alexrashed]

@khaledCNTXT do you think you will have the capacity to fix the last two issues highlighted in the comment above?