So the problem we want to solve is how to let the tf-operator know what namespace its running in.
The operator needs to know what namespace its in so that it can create other resources (e.g. the resource lock) in the same namespace.

The namespace is a property of the runtime environment i.e. the K8s pod. The environment variable should only be set when running on K8s. Furthermore, the namespace should be controlled by setting the namespace you deploy the operator in. The convention in K8s seems to pass this through via environment variables (e.g. this is what the etcd-operator does).

I think the cleanest way to do this is

Use the downward API to set an environment variable on the operator deployment
Have the operator directly read the environment variable.

If the operator uses a flag then we need to set the flag equal to the environment variable. This relies on shell expansion to evaluate the environment variable and set the flag. I think its cleaner to not rely on variable expansion and just access the environment variable directly.

I believe the motivation for this PR was to simplify running the controller locally (not on K8s) in a debug setting. In which case the operator isn't running in a namespace so we can't rely on the downward API to set the environment variable.

This is an exceptional use case since the operator is intended to run on K8s. So I think its perfectly reasonable to make developers explicitly set the NAMESPACE environment variable when running the controller locally.

Should resourcelock be in the same namespace as controller? #352

Description

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions