[janhoy]

🤖 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.

[HoustonPutman]

A side note, Solr should start using better SysVar names for this plugin, so that the EnvUtils code will auto convert envVars... Though we will want to support older versions, so this is great we can just remove allSolrOpts = append(allSolrOpts, "-Davailability_zone=$(SOLR_AVAILABILITY_ZONE)") in the future.

[HoustonPutman]

I like this, but I'd like it even more if we could automatically detect if the setting is enabled in Kubernetes and just use it if it is, and don't if it isn't. Then users wouldn't have to enable it at all.

[janhoy]

I like this, but I'd like it even more if we could automatically detect if the setting is enabled in Kubernetes and just use it if it is, and don't if it isn't. Then users wouldn't have to enable it at all.

That shuold be possible I suppose, do some introspection somewhere and default to true if supported.

Related to this, I also thought about enabling affinity placement plugin as default, with disk warning set to 85% disk used (operator knows pvc size), see #894. But that can be a followup issue once each of the features are included.