You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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
Ignore the missing network policies and risk the reconciliation error when the networking denies access by default
Have a separate mechanism and roll the pods when logging changes and connector operator is disabled
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?
The text was updated successfully, but these errors were encountered:
Discussed on the community call on 18.4.: We should go with the option 3: Have a separate mechanism and roll the pods when logging changes and connector operator is disabled.
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: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:
(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?
The text was updated successfully, but these errors were encountered: