Contour should be better about running in alternate namespaces

[mattmoor]

Please describe the problem you have

I'd like to be able to install Contour into multiple namespaces A, B, C relatively easily, but historically this has been a game of whack-a-mole to try and find all of the places to change to run elsewhere.

The two places that come to mind that burned me are:

1. leader election config default (at least at HEAD this uses the string "projectcontour")
2. the --namespace flag to the certgen job, which I had to dig through code to find because the flag isn't present in the examples.

Where possible, it's generally helpful to use the downward API to load smart defaults (this has helped us in Knative with namespace portability).

[stevesloka]

+1 on downward API =)

[youngnick]

I propose that we:

• Change all the deployment YAMLs to use the Downward API to set a standard env var "CONTOUR_NAMESPACE"
• ensure that anywhere we can specify a namespace on the command line, it is specified in the deployment YAMLs, with the value set to $CONTOUR_NAMESPACE

So, contour certgen would be changed to have the --namespace flag present, and set to $CONTOUR_NAMESPACE, which is set via the downward api.

This will mean that you can change the 'namespace' part of any YAML and have everything just work, which will make automating config easier later.

In addition, there's #2183 and #2246 covering creating command reference documentation. I'm hopeful we can solve those with some automation, as we have with other reference info.

[jpeach]

FWIW here is a working example of deploying Contour multiple disjoint namespaces. In this example, you don't need the certgen --namespace flag, you just run a certgen in each namespace, which has the beneficial result of each namespace using unrelated TLS certificates.

[youngnick]

I don't see anything about certgen in there, without the namespace flag, it looks to me like it will attempt to create secrets in projectcontour by default (although it already has a CONTOUR_NAMESPACE override using Kingpin's env var override), even if you run multiple copies.

Making any namespace flags be explicitly set in the YAMLs provides some in-place documentation of their presence, and enables the "use whatever the current namespace is" behaviour by default, without us needing to add magic everywhere in the code.

[jpeach]

On 26 Feb 2020, at 10:33 am, Nick Young ***@***.***> wrote: I don't see anything about certgen in there, without the namespace flag, it looks to me like it will attempt to create secrets in projectcontour by default (although it already has a CONTOUR_NAMESPACE override using Kingpin's env var override), even if you run multiple copies.

Yeh, looking through the code for the --namespace flag, I think you are right.

Making any namespace flags be explicitly set in the YAMLs provides some in-place documentation of their presence, and enables the "use whatever the current namespace is" behaviour by default, without us needing to add magic everywhere in the code.

IIRC there is a separate proposal to use the current namespace for leader election. It seems that defaulting to using the current namespace for the secrets generation is consistent with that, as well as being easier to configure, though as you point out, you can obtain the same effect using the downward API.

[stevesloka]

Why do we need to specify a namespace at all? Just assume it works in the one you're running it in?

e.g. kubectl apply -f -n projectcontour contour.yaml || kubectl apply -f -n mycustom contour.yaml`?

[youngnick]

Specifying a namespace explicitly using the downward API means that inside the program will know what namespace you are running in - currently some parts of Contour don't know that, and are hardcoded, that's what this issue is for.

If you're proposing that we change those bits to check what namespace they're running in, that's interesting, we could do that.

[stevesloka]

I need to look better at it, but just thinking out loud, what does Contour need from a namespace to be defined either, explicitly or via the downward API?

[youngnick]

It needs to know where to put things it owns, like the leader-election configmap, the secrets created by certgen. I think that's the main reason, and for both of those cases it's probably okay to default to "the current namespace" rather than "projectcontour".

[mattmoor]

FWIW, in Knative (and I think Tekton followed) we use SYSTEM_NAMESPACE (derived from many things using foo-system as their namespace) to convey the namespace in which the controllers are running.

This is ofc far from standard, but I figured I'd at least point it out.