Thank you everyone for participating. Seems like there are no objections to this moving forward. I'll move forward with this donation.
On Fri, Oct 23, 2020 at 8:36 AM Houston Putman <[email protected]> wrote: > I can answer a few of those! > > I assume this is a donation to Solr project, so it will be an >> apache/solr-operator project, similar to how it is currently >> lucene-solr? >> > > Yes, the target would be apache/solr-operator. Similar to > apache/rocketmq-operator <https://github.com/apache/rocketmq-operator>. > > How does this interplay with Docker that IS in-project? >> > > Currently the Dockerfile that is in-project (Solr 9+), is pretty much > identical to the one in docker-solr (Solr 8-). > There is no real difference between the two currently, therefore both are > supported by the Solr Operator. > If the solr/docker image begins to diverge, we will make sure that the > solr-operator supports it since that will be the official Solr docker image > starting in Solr 9. > > Currently the Solr Operator does not have a minimum version of Solr that > it supports, as long as the Solr image is setup the same way as the > official image. > We can begin to start enforcing minimum supported Solr versions if there > are newer Solr features that we want to utilize within the operator. But > there are no current plans to do that . > > - Houston > > On Fri, Oct 23, 2020 at 9:38 AM Alexandre Rafalovitch <[email protected]> > wrote: > >> What would this practically look like if it is adopted/accepted? Given >> the Lucene and Solr separating as an additional wrinkle. >> >> I assume this is a donation to Solr project, so it will be an >> apache/solr-operator project, similar to how it is currently >> lucene-solr? Would the committers be the same or is it kind of a new >> set? Or more like a first-party package? >> >> How does this interplay with Docker that IS in-project? >> >> I am neither plus nor minus on this, just putting the questions that I >> feel would benefit being clarified. >> >> Regards, >> Alex. >> >> On Fri, 23 Oct 2020 at 03:32, Anshum Gupta <[email protected]> >> wrote: >> > >> > Hi everyone, >> > >> > Recently, Bloomberg reached out to us to donate the Solr Operator[1] >> codebase to the Apache Lucene project. >> > >> > Built on the Kube Builder framework, Solr Operator would help in >> standardizing the way SolrCloud clusters are managed in Kubernetes. This >> will allow the community to converge and share best practices around >> managing SolrCloud in k8s world. >> > >> > The PMC has spent the last few weeks discussing the merits and concerns >> around the grant and intends to move forward with it unless there are >> concerns that the community has around it. >> > >> > Thanks to Tim, here’s a detailed document around the design of Solr >> Operator, this should answer most questions around the technicality of the >> project - >> https://docs.google.com/document/d/1uQiJcE7kW5c6iEl9zG1Ve9MTEUGY7OHnMHX8PuTqpY8/edit?usp=sharing >> > >> > I’d also like to summarize the PMC discussions to help reduce repeating >> walking down the same path. >> > >> > Q: Why is having an operator important for the project? >> > A: In todays’ world of cloud native technologies, Kubernetes is an >> essential part of most modern platforms. A Kubernetes Operator allows the >> users of Apache Solr to deploy SolrCloud clusters on k8s while allowing the >> people who understand the system, to codify our collective knowledge about >> how SolrCloud should be operated. >> > >> > Q: Do we want to maintain the Kubernetes operator as part of the Apache >> Lucene project? >> > A: Yes, the operator will become an essential part of Solr as K8s >> adoption grows. Instead of pointing users at third party documentation and >> supporting projects, it would be good to have something that is supported >> by the Solr community. Also, as a separate repository, with a release >> cadence that doesn’t restrict Lucene/Solr releases, the Kubernetes Operator >> will create a lot of value for users. >> > >> > Q: Have we reviewed the design of the operator before accepting the >> grant? >> > A: The project has a lot of commits from Houston, who’s an existing >> committer. Also, Tim (Timothy Potter) has gone through the code and has >> PRs. His document above also provides a lot of insight into the operator >> for the rest of us. Overall, the code seems good and the code is in >> reasonable shape to be accepted and improved. >> > >> > Q: Should we allow the Operator to be incubated as its own project >> instead? If not, why? >> > A: This was considered, but after discussing the pros and cons around >> having the operator come in via the incubator, it was decided otherwise. >> > >> > Q: This is written in a different language i.e. Go. How do we handle >> that? Can we not find something in Java instead ? >> > A: Go is the de-facto language for Kubernetes. We would not get the >> same amount of tooling and support for Kubernetes in Java as Go. As this >> is the right language to move forward with the operator, all of us running >> SolrCloud in K8s will be learning and working with it anyways. We will also >> certainly get questions around it from users, and it makes sense for us to >> lead that instead of catch up. This way we will also attract more >> contributors who know Go and Kubernetes in the future. Most importantly, a >> separate repository will allow us to keep things easy to manage. >> > >> > Q: What about the operator release cadence? >> > A: The operator and Lucene/Solr would have independent release cadence. >> > >> > We would like to give the community a week i.e. until 30th of October, >> 2020 to discuss this so the PMC can make an informed decision. >> > >> > Looking forward to a healthy discussion. >> > >> > [1] https://github.com/bloomberg/solr-operator >> > >> > -- >> > Anshum Gupta >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> -- Anshum Gupta
