Hi Houston, So the general idea is that we'd add a Solr contrib/module, and that module would have a dep on some sort of Kubernetes client so it could manage certain Solr entities (e.g. security.json, configsets, etc.) as Kubernetes resources (configmaps, etc.). Am I understanding that right?
> Please let me know if I can explain more, or how I can make the SIP page > better. One place there might be room for improvement in the writeup so far is around the motivation/value-prop for some of these Solr->Kubernetes integrations. The value in some integrations (e.g. KubernetesSSLCredentialsProvider) is relatively self-evident I think, but others are a little less clear and could use spelled out explicitly IMO. e.g. What's the benefit of storing security.json or configsets in Kubernetes configmaps over ZooKeeper? Best, Jason On Wed, Apr 5, 2023 at 12:45 PM Houston Putman <hous...@apache.org> wrote: > > Hey everyone, > > This is a new SIP, not a duplicate of SIP-17 (Authoscaling on Kubernetes), > and completely unrelated. > > Basically there is a lot of very messy logic we do in the Solr Operator to > bootstrap security and manage various things. This logic must exist because > Solr has no idea that Kubernetes exists. > If we can use Kubernetes APIs to pull in information, instead of relying on > the Solr Operator to inject that information in hacky-ways, the user > experience on Kubernetes is going to get many times better for users > wanting to secure their SolrClouds. This will also help us use > authorization by default (which we always preach) via the Solr Operator. > > This SIP is not very filled out because I'm still thinking on various > aspects. But in general, we can attack the different plugins one-by-one and > the SIP can evolve throughout the process. This SIP is very easy to break > up, which is nice. > > Please let me know if I can explain more, or how I can make the SIP page > better. > > - Houston --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
