ConfigSetService is pluggable, and this works!(*) At Salesforce, we use FileSystemConfigSetService with SolrCloud. Well actually a hybrid thing that we could open-source but we have yet needed it actually, as the only ConfigSet we use is immutable in our docker image.
(*) there is a feature or two that still makes assumptions. A mutable schema is one. On Tue, Jul 9, 2024 at 10:44 AM Houston Putman <hous...@apache.org> wrote: > > I'm not sure this was help up by arguments. The first part that I tried to > tackle was the Kubernetes Config Set management, and that turned into an > absolute beast. > Apparently, a ton of our configSet code relies on the fact that configSets > live in Zookeeper (even though there is an interface...) if Solr is running > in Cloud mode. > > Maybe I'll get this going again but tackle the security plugins first... > That would be a huge win independent of the ConfigSet feature. > > - Houston > > On Tue, May 28, 2024 at 5:53 AM Eric Pugh <ep...@opensourceconnections.com> > wrote: > > > We need a complete path for scaling from the smallest Solr set ups to the > > largest that is well supported by the community, and this seems to be key > > to supporting the largest deployments. So this make sense to me. > > > > Would saying that this kind of change is targeting Solr 10 take some of > > the pressure off of us? Our normal pattern of back porting everything to > > the current branch means that every code change has to be in a releasable > > state, which maybe leads to more discussion. If this is 10x, then maybe > > less pressure? I guess this is really up to whoever or group of whoever > > decide to move this forward ;-). > > > > > > > > > On May 28, 2024, at 5:53 AM, Jan Høydahl <jan...@apache.org> wrote: > > > > > > I think of this from time to time. To get some progress, should be first > > agree in this thread that it is a decent idea, and that a new Solr module > > is warranted for this? > > > > > > I'd hate to see good initatives like this to he held up by arguments not > > related to the code itself but to the lifecycle or wish for separate git > > repos etc. > > > > > > Once we agree to move forward, the JIRA could be split up into > > manageable tasks that more community members could help with. > > > > > > Jan > > > > > > On 2023/04/05 16:45:26 Houston Putman 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 > > > > > > > _______________________ > > Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | > > http://www.opensourceconnections.com < > > http://www.opensourceconnections.com/> | My Free/Busy < > > http://tinyurl.com/eric-cal> > > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < > > https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> > > > > This e-mail and all contents, including attachments, is considered to be > > Company Confidential unless explicitly stated otherwise, regardless of > > whether attachments are marked as such. > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
