Currently, when the connector operator (connector resources / strimzi.io/use-connector-resources annotation) is disabled, we never update the logging configuration - neither dynamically nor through a rolling restart. Not doing the dynamic update is likely caused by the following logic:

• Without the connector operator, users need to manage connectors through REST
• As users need to manage things through REST we cannot setup network policies for it easily as we would block access to it for the users
• Without the network policies, we cannot guarantee that we will have access to the REST API for dynamic configuration

This logic makes sense, but not changing the logging configuration at all due to this seems like a major gap that should be addressed. I guess we have several options:

1. Create the network policy even when the connector operator is disabled and force users to create their own network policies to access the REST API
2. Ignore the missing network policies and risk the reconciliation error when the networking denies access by default
3. Have a separate mechanism and roll the pods when logging changes and connector operator is disabled
4. Ignore it and just document it

(Keep in mind that options 1 and 2 have backward compatibility issues and might break clusters that worked fine until now)

The same logic applies also to the list of available connector plugins. But obviously, that is a lot less serious problem compared to the logging configuration.

I guess in general, we should also think about the future of the connector operator ... I think we have many users using the REST API for one reason or another. So we cannot remove that mode. But should we enable the connector operator by default in our examples? Should we treat the disabled connector operator as a legacy mode we do not prefer and just ignore its limitations (i.e. go with the option 4)? Or do we want to fully support it?

Created by Strimzi#9986