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

[HoustonPutman]

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

So looking through and testing things, there is actually no issue by just turning it on always. It will give an empty string for non-enabled Kubernetes clusters. And solr will handle that gracefully.

I think we should just always use it, and remove the CRD option.

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.

I do like this. There may be a problem with the plugin not allowing multiple of the same replica on the same node, but we can adjust the integration tests to make sure we never get into that state.

[HoustonPutman]

Ok, I added some commits, enabling it by default, and adding the Kubernetes node name as the spread_domain. I'll make a separate PR to have Solr be able to use EnvVars here instead of sysProps, so we can remove the solrOpts part.

Feel free to revert if you don't like it. We can also move this to 1.0 if you don't want a rolling restart included when upgrading to v0.10, though I haven't checked if that will already happen or not.