chart: Allow to customize ingress_namespace env var for Ingress Operator

[aleks-fofanov]

Signed-off-by: Aleksandr Fofanov [email protected]

The changes in this PR will allow to configure ingress_namespace environment variable in Ingress Operator deployment through chart values.

Description

ingress_namespace in Ingress Operator should be configurable because some users would want to pass traffic from function ingress to the gateway deployed to core services namespace (default behavior) while the others may prefer to pass it directly to the function svc in its namespace (bypassGateway option in FunctionIngress object).
Right now the value of this variable is not configurable through chart values. This PR addresses this issue.

Motivation and Context

• I have raised an issue to propose this change (required)

Fixes #661
As discussed in #651, this value should be configurable through chart values for different use-cases.

How Has This Been Tested?

Tested on my local system.
The following verifies that ingress_namespace variable is set through chart values and properly passed down to the operator.

minikube start
kubectl create ns openfaas
kubectl create ns openfaas-fn
helm upgrade -i openfaas \
--namespace openfaas \
--set basic_auth=false \
--set generateBasicAuth=false \
--set ingressOperator.create=true \
--set ingressOperator.ingressNamespace=openfaas-fn \
./chart/openfaas
kubectl -n openfaas describe pods -l app=ingress-operator | grep -A 2 "Environment"

    Environment:
      function_namespace:  openfaas-fn
      ingress_namespace:   openfaas-fn

By default core services namespace is used as ingress_namespace:

helm upgrade openfaas \
--namespace openfaas \
--reuse-values \
--set ingressOperator.ingressNamespace="" \
./chart/openfaas
kubectl -n openfaas rollout status deploy/ingress-operator
kubectl -n openfaas describe pods -l app=ingress-operator | grep -A 2 "Environment"

    Environment:
      function_namespace:  openfaas-fn
      ingress_namespace:   openfaas

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I've read the CONTRIBUTION guide
• I have signed-off my commits with git commit -s
• I have added tests to cover my changes.
• All new and existing tests passed.

[alexellis]

Closing in favour of: #664