[
https://issues.apache.org/jira/browse/SOLR-13661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938982#comment-16938982
]
Jan Høydahl edited comment on SOLR-13661 at 9/26/19 9:35 PM:
-------------------------------------------------------------
Thanks for all the careful responses Ishan, much of what you write makes a lot
of sense. We disagree on others.
You failed to address my point 5 on version dependency conflicts when (rolling)
upgrading Solr.
{quote}We have a disagreement here. Needing the user to edit solrconfig.xml
necessarily in order to specify which collection uses which package is bad from
simplicity standpoint. Please keep in mind that hand editing configset is an
expert feature. No, we're not forcing regular users to do anything extra.
Regular users should be using config APIs to register/deregister their plugins.
Expert users are expert enough to just add an extra package name while they are
hand editing their solrconfig.xml. I think this is a very reasonable compromise.
{quote}
My concern is partly ease of use, but also keeping a config set coherent. The
dependency information that a certain collection will not work without e.g.
Kuromoji analyzer, ICU4J and BMax Query parser belongs there with the config
set, so that we can alert user when creating collection if a dependency is not
met. Thus support for <package>foo</package> tags (or a variant of lib tag as
David suggested) in solrconfig makes perfect sense. Collections are sometimes
moved/copied between clusters. You could install a new cluster fresh, restore
from backup etc. I'm not against a bin/solr package deploy command, but that
command should then add the <package> tag to the collection(s), not to some
global config.
13. I thought of another case, namely backup/restore. I suppose that all
package data from ZK will be backed up and restored. But will blobs be part of
the backup? If not, how would a restore make sure that the blob store is
re-populated? What about CDCR? Will it sync packages and blobs? What if the
other cluster has another Solr version? :)
I'd also vote for targeting 9.0 instead of 8.x. It would make for a great
killer feature. To get the feature out in people's hands we could do an
9.0.0-beta release this fall, while continuing to release 8.4, 8.5 etc
afterwards. Lots of people would start using the alpha release, including 3rd
party plugin developers, and we'd get tons of feedback and time to adjust and
stabilize the APIs. The 9.0.0-beta release could also be a public beta for the
Gradle build which is another thing users (and integrators not the least) needs
to adjust to.
was (Author: janhoy):
Thanks for all the careful responses Ishan, much of what you write makes a lot
of sense. We disagree on others.
You failed to address my point 5 on version dependency conflicts when (rolling)
upgrading Solr.
{quote}We have a disagreement here. Needing the user to edit solrconfig.xml
necessarily in order to specify which collection uses which package is bad from
simplicity standpoint. Please keep in mind that hand editing configset is an
expert feature. No, we're not forcing regular users to do anything extra.
Regular users should be using config APIs to register/deregister their plugins.
Expert users are expert enough to just add an extra package name while they are
hand editing their solrconfig.xml. I think this is a very reasonable compromise.
{quote}
My concern is partly ease of use, but also keeping a config set coherent. The
dependency information that a certain collection will not work without e.g.
Kuromoji analyzer, ICU4J and BMax Query parser belongs there with the config
set, so that we can alert user when creating collection if a dependency is not
met. Thus support for <package>foo</package> tags (or a variant of lib tag as
David suggested) in solrconfig makes perfect sense. Collections are sometimes
moved/copied between clusters. You could install a new cluster fresh, restore
from backup etc. I'm not against a bin/solr package deploy command, but that
command should then add the <package> tag to the collection(s), not to some
global config.
13. I thought of another case, namely backup/restore. I suppose that all
package data from ZK will be backed up and restored. But will blobs be part of
the backup? If not, how would a restore make sure that the blob store is
re-populated?
I'd also vote for targeting 9.0 instead of 8.x. It would make for a great
killer feature. To get the feature out in people's hands we could do an
9.0.0-beta release this fall, while continuing to release 8.4, 8.5 etc
afterwards. Lots of people would start using the alpha release, including 3rd
party plugin developers, and we'd get tons of feedback and time to adjust and
stabilize the APIs. The 9.0.0-beta release could also be a public beta for the
Gradle build which is another thing users (and integrators not the least) needs
to adjust to.
> 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: Major
> Labels: package
> Attachments: plugin-usage.png, repos.png
>
> Time Spent: 20m
> 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: [email protected]
For additional commands, e-mail: [email protected]
