You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by GitBox <gi...@apache.org> on 2022/01/21 17:25:18 UTC
[GitHub] [solr-operator] nickumia-reisys opened a new issue #399: Random Loss of Credentials
nickumia-reisys opened a new issue #399:
URL: https://github.com/apache/solr-operator/issues/399
Hi,
I was searching official documentation and previous issues to see if this issue was ever brought up before, but couldn't find anything. Please let me know what technical information would help you to understand the problem further too.
We have a Solr-Operator instance running that provisioned a 10-node SolrCloud cluster (4 NRT, 2 TLOG, 4 PULL). Everything was functional. It was connected to our main app that was running a solr index operation (~1.3M indexes). Upon randomly checking in on the running index, we noticed that our main app started throwing a `401 Bad Credential` Error. We refreshed the credentials and the application seems to have been able to reconnect to the SolrCloud cluster. However, we're not sure what may have caused the issue.
- From the perspective of Solr-Operator, is there any insight on an unlikely situation/conditions/events that would cause the credentials to be lost in this manner?
In case it's helpful, a capture of the Solr error
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr-operator] nickumia-reisys commented on issue #399: Random Loss of Credentials
Posted by GitBox <gi...@apache.org>.
nickumia-reisys commented on issue #399:
URL: https://github.com/apache/solr-operator/issues/399#issuecomment-1024745521
Hmmm.... so upon further research, it seems like there's a race condition happening in either the `solr` or `solr-operator` helm charts.
Inspecting the pvc that `solr` tries to create,
Inspecting the pod that `solr-operator` tries to create,
<details>
<summary> Full Pod Inspection </summary>
```
nickumia@DL62-2-2MDD043:~/datagov-brokerpak$ kubectl describe pods solr-50d858e0985ecc7f-solrcloud-0
Name: solr-50d858e0985ecc7f-solrcloud-0
Namespace: default
Priority: 2000001000
Priority Class Name: system-node-critical
Node: <none>
Labels: app.kubernetes.io/instance=solr-50d858e0985ecc7f
app.kubernetes.io/managed-by=Helm
app.kubernetes.io/name=solr
app.kubernetes.io/version=8.9.0
controller-revision-hash=solr-50d858e0985ecc7f-solrcloud-74f75459bd
eks.amazonaws.com/fargate-profile=default-namespaces-k8s-5fcb154753056b9c
helm.sh/chart=solr-0.5.0
solr-cloud=solr-50d858e0985ecc7f
statefulset.kubernetes.io/pod-name=solr-50d858e0985ecc7f-solrcloud-0
technology=solr-cloud
Annotations: kubernetes.io/psp: eks.privileged
solr.apache.org/nextScheduledRestart: 2022-01-28T23:20:00Z
solr.apache.org/solrXmlMd5: 843652bc6b529b66f46bcdae6764ab4e
Status: Pending
IP:
IPs: <none>
Controlled By: StatefulSet/solr-50d858e0985ecc7f-solrcloud
Init Containers:
cp-solr-xml:
Image: library/busybox:1.28.0-glibc
Port: <none>
Host Port: <none>
Command:
sh
-c
cp /tmp/solr.xml /tmp-config/solr.xml
Environment: <none>
Mounts:
/tmp from solr-xml (rw)
/tmp-config from data (rw)
/var/run/secrets/kubernetes.io/serviceaccount from default-token-qzccw (ro)
setup-zk:
Image: docker.io/solr:8.11
Port: <none>
Host Port: <none>
Command:
sh
-c
ZK_SECURITY_JSON=$(/opt/solr/server/scripts/cloud-scripts/zkcli.sh -zkhost ${ZK_HOST} -cmd get /security.json); if [ ${#ZK_SECURITY_JSON} -lt 3 ]; then echo $SECURITY_JSON > /tmp/security.json; /opt/solr/server/scripts/cloud-scripts/zkcli.sh -zkhost ${ZK_HOST} -cmd putfile /security.json /tmp/security.json; echo "put security.json in ZK"; fi
Environment:
ZK_HOST: solr-50d858e0985ecc7f-solrcloud-zookeeper-0.solr-50d858e0985ecc7f-solrcloud-zookeeper-headless.default.svc.cluster.local:2181,solr-50d858e0985ecc7f-solrcloud-zookeeper-1.solr-50d858e0985ecc7f-solrcloud-zookeeper-headless.default.svc.cluster.local:2181,solr-50d858e0985ecc7f-solrcloud-zookeeper-2.solr-50d858e0985ecc7f-solrcloud-zookeeper-headless.default.svc.cluster.local:2181/
ZK_CHROOT: /
ZK_SERVER: solr-50d858e0985ecc7f-solrcloud-zookeeper-0.solr-50d858e0985ecc7f-solrcloud-zookeeper-headless.default.svc.cluster.local:2181,solr-50d858e0985ecc7f-solrcloud-zookeeper-1.solr-50d858e0985ecc7f-solrcloud-zookeeper-headless.default.svc.cluster.local:2181,solr-50d858e0985ecc7f-solrcloud-zookeeper-2.solr-50d858e0985ecc7f-solrcloud-zookeeper-headless.default.svc.cluster.local:2181
SECURITY_JSON: <set to the key 'security.json' in secret 'solr-50d858e0985ecc7f-solrcloud-security-bootstrap'> Optional: false
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-qzccw (ro)
Containers:
solrcloud-node:
Image: docker.io/solr:8.11
Port: 8983/TCP
Host Port: 0/TCP
Requests:
cpu: 1
memory: 1G
Liveness: http-get http://:8983/solr/admin/info/system delay=20s timeout=1s period=10s #success=1 #failure=3
Readiness: http-get http://:8983/solr/admin/info/system delay=15s timeout=1s period=5s #success=1 #failure=3
Environment:
SOLR_JAVA_MEM: -Xms300m -Xmx300m
SOLR_HOME: /var/solr/data
SOLR_PORT: 8983
SOLR_NODE_PORT: 80
POD_HOSTNAME: solr-50d858e0985ecc7f-solrcloud-0 (v1:metadata.name)
SOLR_HOST: default-$(POD_HOSTNAME).sub-nickumia40.ssb-dev.data.gov
SOLR_LOG_LEVEL: INFO
GC_TUNE:
SOLR_STOP_WAIT: 55
ZK_HOST: solr-50d858e0985ecc7f-solrcloud-zookeeper-0.solr-50d858e0985ecc7f-solrcloud-zookeeper-headless.default.svc.cluster.local:2181,solr-50d858e0985ecc7f-solrcloud-zookeeper-1.solr-50d858e0985ecc7f-solrcloud-zookeeper-headless.default.svc.cluster.local:2181,solr-50d858e0985ecc7f-solrcloud-zookeeper-2.solr-50d858e0985ecc7f-solrcloud-zookeeper-headless.default.svc.cluster.local:2181/
ZK_CHROOT: /
ZK_SERVER: solr-50d858e0985ecc7f-solrcloud-zookeeper-0.solr-50d858e0985ecc7f-solrcloud-zookeeper-headless.default.svc.cluster.local:2181,solr-50d858e0985ecc7f-solrcloud-zookeeper-1.solr-50d858e0985ecc7f-solrcloud-zookeeper-headless.default.svc.cluster.local:2181,solr-50d858e0985ecc7f-solrcloud-zookeeper-2.solr-50d858e0985ecc7f-solrcloud-zookeeper-headless.default.svc.cluster.local:2181
SOLR_OPTS: -DhostPort=$(SOLR_NODE_PORT)
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-qzccw (ro)
/var/solr/data from data (rw)
Conditions:
Type Status
PodScheduled False
Volumes:
data:
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName: data-solr-50d858e0985ecc7f-solrcloud-0
ReadOnly: false
solr-xml:
Type: ConfigMap (a volume populated by a ConfigMap)
Name: solr-50d858e0985ecc7f-solrcloud-configmap
Optional: false
default-token-qzccw:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-qzccw
Optional: false
QoS Class: Burstable
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 42m fargate-scheduler Pod not supported on Fargate: volumes not supported: data not supported because: PVC data-solr-50d858e0985ecc7f-solrcloud-0 not bound
```
</details>
From my understanding the order of operations is,
1. Create PV
2. Create PVC
3. Create Pod
It seems like the pod is waiting for the PVC to be bound but the PVC is not getting bound because it's waiting for the pod to start up. This may only be an issue because of Fargate issues. I was trying to inspect the [solr helm chart](https://github.com/apache/solr-operator/blob/main/helm/solr/templates/solrcloud.yaml) for an order of operations, but didn't see anything that would represent an order of operations. Can you help verify that there aren't any complex dependencies between the PVC creation and the Pod creation?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr-operator] nickumia-reisys commented on issue #399: Random Loss of Credentials
Posted by GitBox <gi...@apache.org>.
nickumia-reisys commented on issue #399:
URL: https://github.com/apache/solr-operator/issues/399#issuecomment-1021288986
Also, since the zookeepers have ephemeral storage too, would the `security.json` with the credentials possibly be lost on replace/restarts? 🤔
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr-operator] nickumia-reisys commented on issue #399: Random Loss of Credentials
Posted by GitBox <gi...@apache.org>.
nickumia-reisys commented on issue #399:
URL: https://github.com/apache/solr-operator/issues/399#issuecomment-1021277255
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr-operator] nickumia-reisys commented on issue #399: Random Loss of Credentials
Posted by GitBox <gi...@apache.org>.
nickumia-reisys commented on issue #399:
URL: https://github.com/apache/solr-operator/issues/399#issuecomment-1020260325
Follow-up question: Are restarts resilient while a search index is being built?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr-operator] nickumia-reisys commented on issue #399: Random Loss of Credentials
Posted by GitBox <gi...@apache.org>.
nickumia-reisys commented on issue #399:
URL: https://github.com/apache/solr-operator/issues/399#issuecomment-1044915399
I'm so sorry for the delay! We've had a few other issues that we've had to work through.
Updated timeline: We should have the results by the end of next week.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr-operator] nickumia-reisys commented on issue #399: Random Loss of Credentials
Posted by GitBox <gi...@apache.org>.
nickumia-reisys commented on issue #399:
URL: https://github.com/apache/solr-operator/issues/399#issuecomment-1024491330
Hi @HoustonPutman, thanks for your continued support! As we are figuring out how to deploy solr with persistent storage, we're running into a few bumps and would appreciate your confirmation on a few things.
We setup our EKS cluster with an [EFS volume](https://github.com/GSA/datagov-brokerpak-eks/blob/main/terraform/provision/persistent-storage.tf#L137-L155). (EBS doesn't have proper support for Fargate nodes where we are running.) Stupid question, but the `solr-operator` would be happy with EFS too, right?
The EFS volume gets [mounted to all nodes that are started on our cluster](https://github.com/GSA/datagov-brokerpak-eks/blob/main/terraform/provision/persistent-storage.tf#L111-L116) that have a Private IP. We tested this functionality by pulling and running a [test case](https://github.com/GSA/datagov-brokerpak-eks/blob/main/test.sh#L77-L91) from the upstream [aws-efs-csi-driver](https://github.com/kubernetes-sigs/aws-efs-csi-driver/tree/release-1.3/examples/kubernetes/static_provisioning) repo. So we have confidence that EFS is setup for our cluster properly.
I'm trying to provision a `solrcloud` cluster with the `solr-operater` and am running into issues with PVC not being bound to the solrcloud pods. I'm still debugging, but do you have any insights on things I would have to change other than [this](https://github.com/GSA/datagov-brokerpak-solr/blob/solr-optimization-for-ckan/terraform/provision/main.tf#L40-L41)?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr-operator] HoustonPutman commented on issue #399: Random Loss of Credentials
Posted by GitBox <gi...@apache.org>.
HoustonPutman commented on issue #399:
URL: https://github.com/apache/solr-operator/issues/399#issuecomment-1027060321
So there is no issue with the helm charts, or the Solr Operator really.
The Solr Operator utilizes many of the Kubernetes built-in-resources to run Solr, included the `StatefulSet`. The operator relies on Kubernetes to manage the PVCs mostly itself through the StatefulSet controller. As a part of defining a StatefulSet, you can provide a PVC template that it will use to create a PVC for every pod in the statefulSet.
Since your PVCs are not able to be dynamically provisioned, you will need to create your PVs for them to map to before creating your SolrCloud (as you mentioned). You need to make sure that you are creating at least the same number of PVs as the number of SolrCloud pods you have requested.
As to why it can't bind the PVC to your PV, have you made sure that you are setting the same StorageClass for your PV and PVCs (the same one you are creating your PVs with)? The PVCs and PVs cannot bind if they do not have the same storageClassName and meet the size requirements in your PVC. (You can find all of the PVC options for you Solr pods here: https://artifacthub.io/packages/helm/apache-solr/solr#data-storage-options)
Looking through the single PV that you are creating, it is not setting a storage class, while your SolrCloud PVC spec is setting a storage class of "gp2" (as shown in your `kubectl describe pvc` above).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr-operator] HoustonPutman commented on issue #399: Random Loss of Credentials
Posted by GitBox <gi...@apache.org>.
HoustonPutman commented on issue #399:
URL: https://github.com/apache/solr-operator/issues/399#issuecomment-1020273535
Can you explain how you have setup authentication for your SolrCloud? Maybe post the yaml for your solr cloud?
> Follow-up question: Are restarts resilient while a search index is being built?
Yes, if you are using persistent storage for your SolrCloud. If you are using ephemeral, then there are no promises currently. The story there should get better in future versions.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr-operator] nickumia-reisys commented on issue #399: Random Loss of Credentials
Posted by GitBox <gi...@apache.org>.
nickumia-reisys commented on issue #399:
URL: https://github.com/apache/solr-operator/issues/399#issuecomment-1029516809
Hi again @HoustonPutman 😄
We overhauled our implementation a bit. We're,
- using `managed-node-groups` instead of `fargate` (accepting the increased compliance load for our application) and
- implemented the `ebs` EKS addon instead of `efs` EKS addon.
Because of these changes, the `solr-operator` and `solr` helm charts have no issue provisioning PVs and starting solrcloud nodes. We think this will resolve the loss of credentials issue based on discussions in this thread, current testing and general observations. I appreciate your continued guidance on our journey. No need of response yet. I will post back within the next week after we do a full load test.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr-operator] nickumia-reisys commented on issue #399: Random Loss of Credentials
Posted by GitBox <gi...@apache.org>.
nickumia-reisys commented on issue #399:
URL: https://github.com/apache/solr-operator/issues/399#issuecomment-1069266787
I think it's safe to close this issue as the problem was using ephemeral storage for everything. Switching to persistent storage seems to have a stable configuration. Thanks again @HoustonPutman!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr-operator] nickumia-reisys closed issue #399: Random Loss of Credentials
Posted by GitBox <gi...@apache.org>.
nickumia-reisys closed issue #399:
URL: https://github.com/apache/solr-operator/issues/399
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr-operator] HoustonPutman commented on issue #399: Random Loss of Credentials
Posted by GitBox <gi...@apache.org>.
HoustonPutman commented on issue #399:
URL: https://github.com/apache/solr-operator/issues/399#issuecomment-1021438197
> Also, since the zookeepers have ephemeral storage too, would the `security.json` with the credentials possibly be lost on replace/restarts? 🤔
That is certainly possible... You definitely want to be running your ZK cluster with persistent storage.
> We refreshed the credentials and the application seems to have been able to reconnect to the SolrCloud cluster.
What do you mean by refreshed. I'm assuming you created a new authentication keypair and deleted the old one using your terraform scripts?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr-operator] nickumia-reisys commented on issue #399: Random Loss of Credentials
Posted by GitBox <gi...@apache.org>.
nickumia-reisys commented on issue #399:
URL: https://github.com/apache/solr-operator/issues/399#issuecomment-1021277255
> Can you explain how you have setup authentication for your SolrCloud? Maybe post the yaml for your solr cloud?
To support dynamic creation, we have terraform code that runs to create/destroy credentials on-call. Per the [solr-operator docs](https://github.com/apache/solr-operator/blob/main/docs/solr-cloud/solr-cloud-crd.md#option-1-bootstrap-security), it uses the admin password to create/remove new users through the Solr Admin UI.
- [Enable authentication](https://github.com/GSA/datagov-brokerpak-solr/blob/main/terraform/provision/main.tf#L47)
- [Create new authentication login keypair](https://github.com/GSA/datagov-brokerpak-solr/blob/main/terraform/bind/main.tf#L72-L87)
- [Delete existing authentication login keypair](https://github.com/GSA/datagov-brokerpak-solr/blob/main/terraform/bind/main.tf#L102-L117)
> Yes, if you are using persistent storage for your SolrCloud. If you are using ephemeral, then there are no promises currently. The story there should get better in future versions.
Understood. After I asked the question and before you responded, I found your other issue (https://github.com/apache/solr-operator/issues/365). We will be moving to persistent volumes 👍
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr-operator] nickumia-reisys commented on issue #399: Random Loss of Credentials
Posted by GitBox <gi...@apache.org>.
nickumia-reisys commented on issue #399:
URL: https://github.com/apache/solr-operator/issues/399#issuecomment-1021462700
> What do you mean by refreshed. I'm assuming you created a new authentication keypair and deleted the old one using your terraform scripts?
Yes, using the terraform scripts, we destroyed the original credentials and created new credentials.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr-operator] HoustonPutman commented on issue #399: Random Loss of Credentials
Posted by GitBox <gi...@apache.org>.
HoustonPutman commented on issue #399:
URL: https://github.com/apache/solr-operator/issues/399#issuecomment-1021467149
Then I don't think there would be any issue from the solr-operator beyond the ephemeral storage for ZK...
Update this ticket when you've tried that out.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org