You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Shalin Shekhar Mangar (JIRA)" <ji...@apache.org> on 2017/07/22 02:45:03 UTC
[jira] [Comment Edited] (SOLR-10665) POC for a PF4J based plugin
system
[ https://issues.apache.org/jira/browse/SOLR-10665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16097076#comment-16097076 ]
Shalin Shekhar Mangar edited comment on SOLR-10665 at 7/22/17 2:44 AM:
-----------------------------------------------------------------------
Thanks Jan. I have a few comments:
# I think we should split up plugin system and plugin repositories features into separate issues. The former can be designed and built without the latter.
# We should make it easy to build install custom plugins. Perhaps a maven archetype might be useful to bootstrap custom plugin projects.
# SolrCloud presents its own challenges which aren't addressed by the design at all:
## We shouldn't force people to deploy plugins by ssh'ing into each box and restarting Solr
## As Noble said, every node must have the same binary. This must be enforced.
## Are plugins always cluster-level or should we have them on a per collection basis thereby exposing certain plugins only to specific collections.
## I agree with Noble that we should consider enhancing blob store to deal with this use-case.
# The framework must play well with the security API. Only authorized users must be able to install/upgrade/remove plugins. There should be a separate permission for these operations.
# The API can be called just /admin/plugins instead of /admin/pluginbundles
# It is not clear how we can decide if a plugin is incompatible. If we just rely only on versions specified in the manifest, it would mean that every plugin must have a corresponding release for each (major?) Solr release even if it is only to bump the version number in the manifest.
was (Author: shalinmangar):
Thanks Jan. I have a few comments:
# I think we should split up plugin system and plugin repositories features into separate issues. The former can be designed and built without the latter.
# We should make it easy to build install custom plugins. Perhaps a maven archetype might be useful to bootstrap custom plugin projects.
# SolrCloud presents its own challenges which aren't addressed by the design at all:
## We shouldn't force people to deploy plugins by ssh'ing into each box and restarting Solr
## As Noble said, every node must have the same binary. This must be enforced.
## Are plugins always cluster-level or should we have them on a per collection basis thereby exposing certain plugins only to specific collections.
## I agree with Noble that we should consider enhancing blob store to deal with this use-case.
# The framework must play well with the security API. Only authorized users must be able to install/upgrade/remove plugins. There should be a separate permission for these operations.
# The API can be called just /admin/plugins instead of /admin/pluginbundles
> POC for a PF4J based plugin system
> ----------------------------------
>
> Key: SOLR-10665
> URL: https://issues.apache.org/jira/browse/SOLR-10665
> Project: Solr
> Issue Type: New Feature
> Components: Plugin system
> Reporter: Jan Høydahl
> Assignee: Jan Høydahl
> Labels: pf4j, plugins
> Fix For: master (8.0)
>
> Attachments: SOLR-10665.patch
>
>
> In SOLR-5103 we have been discussing improvements to Solr plugin system, with ability to bundle a plugin as zip, and easily install from shell or Admin UI.
> This task aims to create a working POC to demonstrate how PF4J (Plugin Framework4J) can be used to bring a very simple plugin packaging and installation system to Solr with a minimum of effort. Code speaks louder than words :)
> The POC effort is a quite large patch and will be cutting some corners to get the feature in the hands of people who can test and evaluate. If there is consensus to add this to Solr, there will be other sub tasks to split up the elephant into committable chunks.
> The design document is located here: https://s.apache.org/solr-plugin (Google Doc) - comments are welcome in the document or here.
--
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