Support watching a set of namespaces

[hasbro17]

Feature Request

Support restricting the operator to only watch a set of namespaces.

The controller-runtime's manager currently only allows the cache to be restricted to a single namespace or all namespaces. This forces the permissions model to either be a ClusterRole/ClusterRoleBinding to watch all namespaces, or a Role/RoleBinding to watch a single namespace.

When watching resources across a set of namespaces however we can have a ClusterRole with multiple RoleBindings(each referring to the operator's service account).

Proposed fix:
Long term: Follow up on kubernetes-sigs/controller-runtime#124 (comment) upstream and add support for the MultiListWatcher to support this in the controller runtime.

Short term: While it might take some time to add the change upstream we can have our own cache implementation in SDK that supports a set of namespaces, and override the manager's GetCache() method for all dependent objects.

e.g:

type OurManager struct {
     manager.Manager
     cache ourCache
}

func GetCache() {
    return cache
}

[ironcladlou]

For the use cases where people want to work with multiple namespaces, I'm now wondering if this is more of a documentation issue. Based on a tip from the kubebuilder book I was able to support multi-namespace with minimal fuss and no new features/wrappers.

[shawn-hurley]

@ironcladlou I think that I have discussed this before, but the solution that you are you using has some severe problems with the default client that we would expect folks to use. The way that you are doing things is clever and works for your use case.

I think that this is an issue that we want to solve, either here or upstream.

[ironcladlou]

I agree it's still not ideal. My solution does imply an understanding of how to deal with a mixture of scoped/caching clients and live clients, and ensuring they share schemes, etc. Probably not a reasonable expectation for most users.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[hasbro17]

/remove-lifecycle stale

This is coming up with the stable release of controller-runtime v0.2.0, currently v0.2.0-alpha.0

ref: #1388

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[navidsh]

@estroz Is there any doc/guide about how to use this feature now that it is supported?