search

apache / solr-operator

Official Kubernetes operator for Apache Solr
https://solr.apache.org/operator
Apache License 2.0
242 stars 112 forks source link

zkHost and zkServer generated incorrectly - helm templates #704

Closed brickpattern closed 1 month ago

brickpattern commented 1 month ago

Observed the POD has a EnvVar with zkHost and zkServer set incorrectly ( generated from helm install )

-DzkHost=solr-solrcloud-zookeeper-0.solr-solrcloud-zookeeper-headless.solr.svc.cluster.local:2181,solr-solrcloud-zookeeper-1.solr-solrcloud-zookeeper-headless.solr.svc.cluster.local:2181,solr-solrcloud-zookeeper-1.solr-solrcloud-zookeeper-headless.solr.svc.cluster.local:2181/

The service name created for the ZK is solr-solrcloud-zookeeper-headless The Pod name created are solr-solrcloud-zookeeper-0 and so forth the zkHost got both podname and service name concatenated.

Looking at the helm template files, the EnvVar is set from PodOptions.EvnVar which remains empty in my helm yaml file. So its getting generated from code

brickpattern commented 1 month ago

after looking at what the Zookeeper charts are doing, its establishing the DOMAIN for the service as "solr-solrcloud-zookeeper-headless"

Even though the name resolution in linux is 5 Dot notation, that is meant to come out as svcname.namespace.svc.cluste.local

this injection of Domain in between is still resolved after restarting the SolrCloud pods.

So essentially when both ZK and SolrCloud starts , the name is unresolved. But once ZK cluster is all settled, restarting SolrCloud does the resolution properly.

brickpattern commented 1 month ago

closing