janhoy opened a new pull request, #892: URL: https://github.com/apache/solr-operator/pull/892
🤖 AI assisted 🤖 Closes #556 Solr's `AffinityPlacementFactory` spreads replicas across availability zones using each node's `availability_zone` system property. Getting that value into a Solr pod used to mean a hand-written init container that queried the API server for node labels, which needs node-read RBAC. The gist in the issue is the workaround people have been copying. Kubernetes solved this: the `PodTopologyLabels` admission plugin copies the node's `topology.kubernetes.io/zone` label onto the pod at binding time, alpha in 1.33 and beta, on by default, since 1.35. So the value is now reachable through the Downward API with no RBAC and no init container. New opt-in SolrCloud field `availabilityZoneFromNodeLabel`, exposed as the Helm value `solrOptions.availabilityZoneFromNodeLabel`. When set, the operator adds a `SOLR_AVAILABILITY_ZONE` envVar from the pod label and appends `-Davailability_zone=$(SOLR_AVAILABILITY_ZONE)` to `SOLR_OPTS`. It is opt-in rather than automatic for two reasons: enabling it changes the pod spec, which costs a rolling restart, and on a cluster without the feature the label is absent so the property would be empty. Empty is harmless, since Solr then treats all nodes as one zone, exactly as it does today when no node reports a zone. Only the zone label is wired up. Region and hostname are also copied by the plugin, but Solr's placement plugins have no use for them today. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
