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.
