This would be a new repo under apache/ in git. It would share the committers and PMC members i.e. until the split of the project is complete, it would belong to the current project and once the split is done, we would move this over into the Solr project. As I already mentioned in the earlier email, the release cadence of this project would be different than core Solr, so as not to block the core releases. This isn't a package but a standalone repo that has nothing to do with a running Solr process.
How does this interplay with Docker that IS in-project? The dependency is Solr <-- Solr-Docker <-- Solr-Operator. Once e.g. Solr 9.0 is out, the solr-operator may only support Solr8.x for some time. Releasing a solr-operator version that supports solr 9.0, possibly with support for migrating an existing cluster, or not depending on the goals of the sub project would happen independently. The operator will depend mostly on the Docker images produced by Solr. The primary integration points are bin/solr and all its options / env vars and the API. So unless Solr’s test base and release process allows someone to break back compat when they’re doing a release, breaking the operator isn’t that much of a concern. This is another reason we don’t want to rebuild the Collection API in the operator. On Fri, Oct 23, 2020 at 6:38 AM Alexandre Rafalovitch <arafa...@gmail.com> 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 <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 > > -- Anshum Gupta
