Closed lavocatt closed 5 months ago
I opened this from the observation that there seemed to be some duplication here, and though to remove all uses of OPERATOR_WATCH_NAMESPACE assuming that the same capability would be available through WATCH_NAMESPACE and assuming that both would be set.
But it is typically never that simple, and removing an env var is usually non trivial from a backward comparability point of view. If it is a simple swap, and WATCH_NAMESPACE is always present when OPERATOR_WATCH_NAMESPACE is set, the I think we can do it.
In short, this issue has been open for a while because it is not clear what the value or the potential impact is.
Part of the context was in moving to an operator that is only cluster wide, but even then, it may be good to be able to limit the cluster wide operation, but if that was the case, it should be an operator sdk deployment thing, rather than something that was unique to our operator.
In short, I don't know for sure and have not investigated in any detail.
I'm closing this PR for now, since it's stale and I'm working on other topics atm.
Replace the custom env variable OPERATOR_WATCH_NAMESPACE with WATCH_NAMESPACE.
@gtully I'm wondering though if that's what you had in mind in the issue or if you meant to remove all the code related to
OPERATOR_WATCH_NAMESPACE
. If it's the later, then we'll have to also rethink theisLocalOnly
function. Let me know your thoughts on this.