Attila Mészáros

@gyfora So you proposing something like: if a new namespace is added dynamically in runtime, and there is an informer (among possible more new informers), that cannot be start because...

However validating the namespace list and related permissions, and filtering the namespace list, could be something outside of the operator.

ok I understand what you mean. Good point. However consider a situation: somebody accidentally mis-configures the rbac, and revokes just permission of a single resource in a namespace, while the...

The other alternative to solve both the issues, just retry staring the informer with some exponential backoff, and log warning. Assuming that it won't reconcile the resource anyways since there...

Yes, that will cover this case in a relatively simple way. But would put there a feature flag, by default will exit if one of the informers is stopped. And...

see related issue: https://github.com/fabric8io/kubernetes-client/issues/4527

I think it should be rather nullable, thus `controller.getConfiguration().getRetryConfiguration()` should return an `Optional`? That is better describing the domain, that there might not be a retry.

Event Sources are generally for that. It is certainly possible.

@andreaTP given the type-safety nature of CRD-s this should basically never happen in general. If there are some additional validations in addition to OpenAPI validation that could be also handled...

> I do believe that, for production-grade Operators, we should be able to somehow show(and propagate to the user logic) the fact that something is going wrong and avoid swallowing...