helm, --namespace with --tcp-services-configmap.

[kfox1111]

NGINX Ingress controller version:
Helm chart version:
version: 3.23.0
ingress-nginx:
0.44.0

Kubernetes version (use kubectl version):
Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.10", GitCommit:"98d5dc5d36d34a7ee13368a7893dcb400ec4e566", GitTreeState:"clean", BuildDate:"2021-04-15T03:20:25Z", GoVersion:"go1.15.10", Compiler:"gc", Platform:"linux/amd64"}

Environment:
NA.

What happened:

We upgraded a cluster from stable/nginx-ingress:
chart version: 1.34.2
to the ingress-nginx chart.

There is a problem that we cant work around now.

We typically setup an ingress-nginx instance that is namespaced to a particular namespace for each project.
When using the newer chart, it can not find the configmap, as its only watching for the namespaced one, not the namespace the ingress controller is in.

In the older chart, it would load a configmap for TCP proxying into the release namespace but then configure the ingress-controller to look for it in the namespace flagged name:
https://github.com/helm/charts/blob/master/stable/nginx-ingress/templates/controller-deployment.yaml#L105
via {{ default .Release.Namespace .Values.controller.tcp.configMapNamespace }}

But now in upstream ingress-nginx, it does not support that as a workaround:
https://github.com/kubernetes/ingress-nginx/blob/master/charts/ingress-nginx/templates/controller-deployment.yaml#L89
it hardcodes $(POD_NAMESPACE)

What you expected to happen:

Ideally, when using tcp and namespace, things should "just work". But it fails due to the watch on namespace.

Either ingress-nginx needs to watch the namespace the --tcp-services-configmap points at in addition to --namespace, or the namespace passed to --tcp-services-configmap in the chart needs to be overridable so it can be set to the same thing as --namespace.

How to reproduce it:

helm install with these values into the namespace named test-admin

controller:
  scope:
    namespace: test
#    tcp:
#      configMapNamespace: test
  tcp:
    "22": test/gitlab-gitlab-shell:22

Look at the ingress logs, and it will complain about not being able to find the configmap.

The commented out values were our workaround to get it to work on the older chart.

/kind bug

[tao12345666333]

/area helm

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[kundan2707]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.