[GitHub] [solr] colvinco commented on pull request #1321: SOLR-13396 - Add property to disable deletion of unknown cores

["colvinco (via GitHub)" <gi...@apache.org>]

colvinco commented on PR #1321:
URL: https://github.com/apache/solr/pull/1321#issuecomment-1412401969

   > I'm ok with either _preserve_ or _delete_. If you rather want _delete_ then choose it, with a java-level default of "true".
   > 
   > Do we need to treat this behaviour as a backward compatibility promise? If Solr 9.2 starts preserving cores, and it is documented in the upgrade notes, no client ode needs to be changed anywhere. 
   
   Thanks for reviewing Jan :)
   Just to confirm what you're saying, you're okay with the idea of changing the existing behavior so that it no longer automatically deletes unknown cores (and documenting accordingly)? Just checking because when you said `If you rather want _delete_ then choose it, with a java-level default of "true".` that would keep the existing behavior of deleting cores by default, wouldn't it?
   
   > Only users who perhaps explicitly modifies cluster-state directly in ZK and have high core churn, i.e. rely on current behavior to reclaim disk space, would suffer. Or do I understand the domain right?
   
   My understanding is that the original motivation for the automatic deletion was to clean up after autoscaling operations or explicit deletes occurring when one or more nodes hosting replicas of the collection are offline SOLR-12066. Some of the comments on SOLR-13396 from 2019 suggest that manual cleanup on a large cluster would be painful. I don't know what the majority wants for this as a default. Not deleting is definitely the safest IMO.
   
   I see that some of the comments on the issue suggest some better end-to-end solutions which might put the administrator in the loop so that they can action/authorize the deletion, which sounds like a good long term solution.
   
   We're currently using Solr 8 for our product with several modifications that we maintain, my (selfish :)) motivation is to get onto Solr 9 without any modification to the distribution, in the not too distant future. Configuration options are good enough for that stepping stone.


-- 
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