[
https://issues.apache.org/jira/browse/SOLR-13661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16945481#comment-16945481
]
Jan Høydahl commented on SOLR-13661:
------------------------------------
{quote}[~noble.paul]: Rolling restarts are NEVER REQUIRED. Solr behaves very
badly during rolling restarts, we lose shards/replicas or our overseer get
clogged with messages and needs manual intervention.
{quote}
I understand the objective of hot update not needing restart. But in my point
5) i was talking about *rolling upgrades* as officially documented and
recommended in ref-guide
([https://lucene.apache.org/solr/guide/8_1/upgrading-a-solr-cluster.html)]. I
hear you say that you personally have bad experience with rolling restarts, but
are you also saying that the new package design is incompatible with the
rolling upgrade procedure?
If we still want to support rolling upgrade, I think it is crucial that we have
a well designed and tested story for package upgrades during a rolling restart
where some nodes are 8.x and other nodes are 9.x. In that case ZK as source of
truth for which plugin version a collection has is simply not good enough. Each
node must be able to choose and upgrade a package to a package version that is
compatible with the new Solr version.
That is part of the reason I want a static/cold way of installing a package and
resolve version, before the node is even started. And on node startup, the node
needs to validate every package/plugin and refuse to start if an active
package's version constraint is not satisfied. It must then be possible to
upgrade packages on that node (which is just upgrade to 9.0) only without
forcing the same version of a package for all other nodes (which still run Solr
8.x).
Plugin/package authors are of course encouraged to make sure their plugins will
not break if two versions are in use by the same cluster at the same time. This
may be challenging for e.g. LTR that use shared data files (such as ML models).
But I guess it will have to be handled and documented in the same way we do for
Solr in general. E.g. "In order to upgrade to LTR v9.0 you first need to be
running v 8.x which supports both old and new model format" or similar. Ideally
such upgrade requirements would be possible to encode in the manifest.
> A package management system for Solr
> ------------------------------------
>
> Key: SOLR-13661
> URL: https://issues.apache.org/jira/browse/SOLR-13661
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Noble Paul
> Assignee: Ishan Chattopadhyaya
> Priority: Blocker
> Labels: package
> Attachments: plugin-usage.png, repos.png
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Here's the design doc:
> https://docs.google.com/document/d/15b3m3i3NFDKbhkhX_BN0MgvPGZaBj34TKNF2-UNC3U8/edit?usp=sharing
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
