priorityClassName for Zookeeper

[alexangas]

I'd like to ensure that Zookeeper pods take priority over Solr pods, so that the ZK configuration is more likely to be available for Solr. I haven't seen a lot of how well newer versions of Solr behave when ZK is not available, but have seen problems with older versions.

Is it possible to specify priorityClassName for Zookeeper? Am I thinking about this the right way?

[HoustonPutman]

Solr is never going to work when ZK is unavailable, so this is definitely something to think about.

I did find this: https://github.com/pravega/zookeeper-operator/issues/438

And looking at the code it doesn't look like the Zookeeper Operator supports this. You can always use the Bitnami ZK Helm chart (probably better than the zookeeper operator anyways) and pass the connection string to Solr instead of using the "provided zookeeper".

[alexangas]

I'm struggling to understand the benefit of Zookeeper Operator. It seems to be stuck in alpha, missing features, and is not part of the Apache project.

Why would someone use it over something like Bitnami?

[janhoy]

I have fiddled with the same question. ZK Operator almost looks like abandonware, which worries me. I tried to ping for a new release of pravega/zookeeper docker image in https://github.com/pravega/zookeeper-operator/pull/515 but no progress. The whole repo was stale since October'22 but there were 3 commits yesterday, so still some activity.

The managed zk feature of solr-operator is great. Would be a pity if all users had to manually configure bitnami chart for every new solr cluster, and feed the ZK connection string into solr. Are there ways do do a tighter integration with binami out of the box?

[iampranabroy]

I may be lacking some insights here, but @HoustonPutman @janhoy how would it impact if we were to use the bitnami zookeeper (looks much more active) chart instead of the pravega/zookeeper-operator chart? I don't see any operator there, then maybe the Solr operator needs to take care of the zookeeper-cluster there, which now the zookeeper-operator does.

[HoustonPutman]

The managed zk feature of solr-operator is great. Would be a pity if all users had to manually configure bitnami chart for every new solr cluster, and feed the ZK connection string into solr. Are there ways do do a tighter integration with binami out of the box?

I'm not sure this is possible unfortunately. Maybe we could ask for a bitnami chart release name and make some guesses about other stuff, but it seems weird.

I may be lacking some insights here, but @HoustonPutman @janhoy how would it impact if we were to use the bitnami zookeeper (looks much more active) chart instead of the pravega/zookeeper-operator chart? I don't see any operator there, then maybe the Solr operator needs to take care of the zookeeper-cluster there, which now the zookeeper-operator does.

So the bitnami zookeeper chart isn't an operator, it just uses the built in kubernetes resources to implement Zookeeper. The solr operator is never going to "take care" of zookeeper nodes, because its purpose is to run Solr. I've used the bitnami chart and it looks like there is very little need for "operator" functionality for zookeeper clusters, but I could be wrong there.