On Sat, Mar 29, 2025 at 9:52 PM Luke Kot-Zaniewski (BLOOMBERG/ 919 3RD A) < lkotzanie...@bloomberg.net> wrote:
> Hi David, > > I appreciate the partial answers and apologize for the > late reply. > > I did read up a little bit on Istio/Envoy/iptables and > it does sound interesting although it would be a massive > architectural shift for us with certain other maintenance > costs + learning curve. There are definitely benefits ... > I've already ran into situations where I wished I had a > service mesh so that, for instance, switching Solr 5-8 clouds > to TLS worked the same as 9 but alas.. > It was a huge shift for us at work too; I understand! It's pleasantly super transparent and care-free on the other side :-) > Just for my own understanding, each Solr node in your set-up > has its own envoy sidecar and the cloud is technically running > in http-mode because the envoy-to-envoy traffic is already > TLS? I assume then you must override the solr host names of > each node to some fqdn that istio/envoy can resolve? > Yes. Solr has no clue. And yes to the DNS/host names. It's basically taken care of by the infrastructure at a ~k8s layer. > At any rate, after hearing your take I think I'll skip the > rabbit hole of figuring out why the "Solr-native" TLS has > this weird base_url corruption during transition since this > isn't the most modern way of doing it anyway and anyone converting > to TLS should be encouraged to do so at the infra level. > Istio/Mesh may be modern and wonderful but I sense it's still uncommon. Thus if you were to improve the TLS parts of Solr, it would be quite relevant to the vast majority of users. We made improvements prior to us making the big shift. ~ David
