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