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
