Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate official support for the SolrCollection and SolrCollectionAlias CRDs #204

Closed
HoustonPutman opened this issue Jan 28, 2021 · 2 comments · Fixed by #206
Closed
Milestone

Comments

@HoustonPutman
Copy link
Contributor

The SolrCollection and SolrCollectionAlias CRDs are nice constructs that allow users to create Solr collections and aliases through Kubernetes APIs (and tools, such as kubectl).

The issue with having these is that the internal state of Solr is replicated in two places, EtcD (where the API Server saves all Kubernetes resources) and Zookeeper (where Solr keeps its internal state). This naturally leads to the problem of how do we keep these two sources of information up-to-date. One solution would be to use SolrJ APIs to watch Zookeeper for changes to the state and make those updates in the API Server. However if a change happens in the API Server and Zookeeper at the same time, which should we prefer? Also since the Solr Operator is written in Go, these convenient SolrJ APIs are not available to us.

In general, Solr has nice HTTP APIs that allow for management of collections and aliases. The Kube CRD representations of them only provide a wrapper for users to interact, they provide no runtime benefits within the system.

For this reason the Apache Lucene (and Solr) PMC has decided to remove these two CRDs from the official repo and allow the community to take control of them. They would still be able to interact with the official Apache Solr CRDs in the same way, however the controllers would live in a separate binary and would be released under in a different cadence.
The v0.2.8 release will be the last release in which these CRDs will be monitored by the Solr Operator.
We will provide documentation in the upgrade instructions on how to safely remove these CRDs or migrate them to their new locations when upgrading to v0.3.0.

CRDs that deal with runtime of Solr and its peripheral systems will continue to be official Apache Solr CRDS and be supported fully. Currently this includes the SolrCloud, SolrPrometheusExporter and SolrBackup CRDS.

@HoustonPutman HoustonPutman added this to the v0.3.0 milestone Jan 28, 2021
@sepulworld
Copy link
Contributor

sepulworld commented Jan 28, 2021

I can help with this. I was thinking we could start a Terraform Provider and automate resource management for Collections, Alias, and Config Sets with it. If users of lucene-solr-operator also use Terraform as part of there infra automation tool set and like this idea, let me know. 👍

@sch1ldkr0ete
Copy link

Hi. Thanks for the awesome operator!

Did the SolrCollection CRD got a new location in the end?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants