Add namespace to manifests, to support devspace render / helm template about component-chart HOT 3 OPEN

It's an interesting idea but I'm not sure about it because it may be better to have one application definition that can be applied to x namespaces.

Can't you simply set the target namespace (destination) in Argo and that should achieve what you want? In the application definition rather than in the manifests: spec.destination.namespace

If we were to add the namespace in the output and you wanted an application deployed x times in x namespaces, that would not be possible anymore. Right now, it's easily possible by commiting one singe output of devspace to git and have multiple Argo applications with different namespaces.

from component-chart.

It's an interesting idea but I'm not sure about it because it may be better to have one application definition that can be applied to x namespaces.

Can't you simply set the target namespace (destination) in Argo and that should achieve what you want? In the application definition rather than in the manifests: spec.destination.namespace

If we were to add the namespace in the output and you wanted an application deployed x times in x namespaces, that would not be possible anymore. Right now, it's easily possible by commiting one singe output of devspace to git and have multiple Argo applications with different namespaces.

Hi @LukasGentele , thanks for taking the time. I understand your point of view and your proposed solution, which unfortunately doesn't apply to me because I am not using exactly argocd but another similar product.
Can I then propose an alternate solution, which is using a specific value namespace. then the chart could have something like:

{{- if .Values.namespace-}}
  namespace: {{- .Values.namespace -}}
{{- end -}}

The value name can be anything you'd like of course. And I'd be happy to submit a PR.

from component-chart.

Great idea to work with values instead. Looking at devspace-sh/devspace#1782 , we may want to make this more flexible, e.g.

namespace:
  name: xxx
  annotations: ...  # can be added later
  labels: ...             # can be added later

While name is the only thing we need at first, to add namespace to the service, deployment etc. (= your issue) making the namespace as an object may be more flexible for down the road if we want to add other things to the namespace definition itself (= referenced issue above).

Any thoughts regarding their solution for either one of these issues? Would that work for you?

Thanks for suggesting this @wollowizard! Would love to see a PR from you. Please note that you'd also need to add a PR to DevSpace itself to add the new values options of the component chart to the devspace.yaml

from component-chart.