janhoy opened a new issue, #600: URL: https://github.com/apache/solr-operator/issues/600
Ref discussions in https://github.com/apache/solr-operator/issues/517#issuecomment-1428310490 The ZK operator is a project that is not well maintained ([74 open issues](https://github.com/pravega/zookeeper-operator/issues) and no response to PRs). They lag in releases (on zk 3.7.1 while latest is 3.9.0) and you cannot even upgrade Zookeeper by referencing another ZK docker image, since the zk-operator require their own custom image with some added tools. This *will* be a problem in the future unless pravega ups their game one this. Other issues with the architecture: * it is a bit awkward to have the Solr operator add a CRD for the Zk operator to pick up. Hard to debug issues. * If you try to delete a solr cluster in e.g. ArgoCD, it will try to delete leaf resources first, not being aware that they are managed by ZK-operator, so ZK-operator will re-create them in an endless loop * Upgrading Solr operator requires manual upgrading of zk-operator CRD in the right order.. * ZK-operator POD runs as root and there is no way to patch the pod-spec through Solr-operator :( So let's consider declaring the zk-operator support deprecated. We can then either recommend users to use bitnami ZK chart separately and copy the ZK address. Or if possible, a tighter integration where you can just provide a namespace+name and let solr-operator figure out the connection string. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
