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 <ans...@anshumgupta.net> 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
