lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hrishikesh Gadre (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-11229) Add a configuration upgrade tool for Solr
Date Fri, 18 Aug 2017 19:11:00 GMT

    [ https://issues.apache.org/jira/browse/SOLR-11229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16133497#comment-16133497
] 

Hrishikesh Gadre commented on SOLR-11229:
-----------------------------------------

[~gerlowskija] Thanks for your feedback.

bq. I noticed that the TODO list in the README.md doesn't mention anything about Windows support.
Is a Windows version of this script in the scope of this JIRA? Or is the idea that it'd be
added as a part of a separate JIRA later on?

Sure - we can add windows support as part of this jira itself. I didn't think about Windows
support earlier.

bq. I notice that ConfigUpgradeTool mimics but doesnt technically implement the Solr Tool
interface. Is the idea that as this makes its way into Solr, it would actually implement that
interface? Or is it coincidence that those classes look similar. This is not a suggestion
or a critique; just trying to understand the code a little better.

Sure I think it would be a good idea to use Solr Tool interface for this tool as well. 

bq. I'm curious about the choice of XSLT here.

One of the important requirement is the ability to accept a Solr configuration file (e.g.
solrconfig.xml) of version X and emit a identical configuration compatible with version Y
(e.g. rewriting some of the configuration sections). As per my understanding XSLT is designed
for such use-cases (while XPath is more useful towards querying the XML document). Obviously
we can cobble together some java/bash code along with XPath to make it work. But I felt using
a single technology to handle both querying and transformation would simplify the tool as
well as implementation of upgrade rules.

Note -  I personally found XSLT to be adequate to implement all the upgrade rules from Solr
4 -> Solr 6. It took me about an 1 1/2 to read the Upgrade section in the release notes
and implement the upgrade rules for one release (e.g. from Solr 4 -> Solr 5). And now we
have some reference available, new rules can easily be added by referring to these definitions.


> Add a configuration upgrade tool for Solr
> -----------------------------------------
>
>                 Key: SOLR-11229
>                 URL: https://issues.apache.org/jira/browse/SOLR-11229
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>    Affects Versions: 6.6
>            Reporter: Hrishikesh Gadre
>
> Despite widespread enterprise adoption, Solr lacks automated upgrade tooling. It has
long been a challenge for users to understand the implications of a Solr upgrade. Users must
manually review the Solr release notes to identify configuration changes either to fix backwards
incompatibilities or to utilize latest features in the new version. Additionally, users must
identify a way to migrate existing index data to the new version (either via an index upgrade
or re-indexing the raw data).
> Solr config upgrade tool aims to simplify the upgrade process by providing upgrade instructions
tailored to your configuration. These instructions can help you to answer following questions
> - Does my Solr configuration have any backwards incompatible sections? If yes which ones?
> - For each of the incompatibility - what do I need to do to fix this incompatibility?
Where can I get more information about why this incompatibility was introduced (e.g. references
to Lucene/Solr jiras)?
> - Are there any changes in Lucene/Solr which would require me to do a full reindexing
OR can I get away with an index upgrade?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message