namespace apprepo-controller kube informer

[prydonius]

The NewFilteredSharedInformerFactory was not available in previous versions
of client-go we were using. Now that we've upgraded, we can correctly
filter down to the namespace this controller is interested in
(the one Kubeapps is installed in).

chart: remove clusterrole for apprepository-controller

Now that we are able to watch on the specific namespace Kubeapps was
installed in, we no longer need the clusterrole to watch cluster-wide
CronJobs.

fixes #504

[migmartri]

Awesome.

Any test changes required or worth adding?

[prydonius]

@migmartri I'm not sure, the tests are currently for controller.go only, and I don't know if we can mock the shared informers? Even if we did test mocked informers, we'd be passing an initialised informer to the controller, so we won't actually be able to test this particular change. I believe this is something only an e2e test would be able to verify. @andresmgot may have some more ideas though.

[andresmgot]

I don't think we need an unit test for this change (since the call is syntactically correct).

What I don't fully understand is why do we need to listen for CronJobs: Apparently is to be safe and recreate a CronJob that someone deletes manually, am I right? If we really care about that we could add an e2e test to check that the CronJob gets recreated but I don't think it's necessary.

[migmartri]

I don't think we need an unit test for this change (since the call is syntactically correct).

What I don't fully understand is why do we need to listen for CronJobs: Apparently is to be safe and recreate a CronJob that someone deletes manually, am I right? If we really care about that we could add an e2e test to check that the CronJob gets recreated but I don't think it's necessary.

@prydonius, would you mind adding a comment to make it more clear? Thanks!

[prydonius]

@migmartri updated the comment to make it more clear