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
If I manually delete the proxy configmap, the operator can get into a bad state where it's waiting for the proxy pods to come up, but they can't come up because the configmap is missing.
A workaround for this was to disable and then re-enable TLS on the proxy to force a new config to be created.
The text was updated successfully, but these errors were encountered:
The operator doesn't watch the generated resources. In order to implement this, we have to use the JOSDK secondary resource concept. This would be a huge change and I'm not sure it's worth
It seems like the operator should have some way to bring the cluster back into a working state. Since the operator creates the configmap it should also include some way to re-sync it. Maybe have a timeout on proxy deployment readiness where it will re-apply the configmap if the proxy, or other resource, fails to become ready? Or check all resources at startup so that an operator restart will fix the issue?
If I manually delete the proxy configmap, the operator can get into a bad state where it's waiting for the proxy pods to come up, but they can't come up because the configmap is missing.
A workaround for this was to disable and then re-enable TLS on the proxy to force a new config to be created.
The text was updated successfully, but these errors were encountered: