[
https://issues.apache.org/jira/browse/SOLR-13661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16938991#comment-16938991
]
Noble Paul commented on SOLR-13661:
-----------------------------------
bq.Simplicity should be front seat. Don't force users to have to add
{{package="my-pkg"}}
A name is something everyone needs . A package name is an extremely important
aspect. You cannot load reload plugins from a package we do not know the name
of the package. Just a class name means nothing. Isolated classloaders are
extremely important. Every sensible platform is built with isolation.
We can possibly later add a global feature called , {{config-package= mypkg}} .
This would mean that every plugin will load from {{mypkg}}. There is no reason
why it cannot be added later. But, not being able to load a plugins from
multiple packages is a strict NO. You are just ensuring that multiple packages
from multiple plugin writers cannot coexist.
Another issue id backward incompatibility. The new class loader design is
different and it can break current deploymemts
This new design totally disallows per core classloaders. This can be a problem
for users who use Solr with core level libs. So, it has to be backward
incompatble as well
bq.Robustness during upgrades is another concern. I don't see mentioned in the
design doc what happens during a Solr upgrade.
I'm not sure you have read the design properly. Robustness of design is the
paramount feature of this design. We went out of our way to ensure that
"update" is non-disruptive. 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.
Overall feedback on your feedback [~janhoy]
I'm happy to receive and address feedback. We need to divide the following parts
# Enhancements which can be implemented with the current design . But the
current design is meeting the minimum viable product and does not obstruct or
hamper implementing an enhancement
# The current design is suboptimal or bad UX
# Comments on "inadequate eyes" etc. We are an OSS project and we don't work
in the same org. So collaboration is always "inadequate" . We should always
work towards having 100% collaboration in every single feature that we build.
The fact that we are discussing this here means that we can have collaboration
as long as people are interested in it. So, please refrain from giving this
"feedback". We should keep the comments short and sweet and make them
"actionable"
I'll give examples of #1 and #2
h3. using a Package.java to load plugins
This falls into #1
Is this a good suggestion? I would say it's questionable. But, I won't delve
into that here.
But, can we implement it if required in the future? Yes, of course. Does it
have to be discussed in this ticket? I would say it's out of the scope.
h3. Changing the blob names to hash-filename
This falls into #2
This is a usability issue. I had thought about this while building it, ab had
raised the concern in he design doc. It is probably something we should
address before committing this. If you have gone through the comments you would
have seen it.
Let's keep the feedback coming. But let's not distract from the current task at
hand. We don't have a working useful package management system today and a
minimum viable product is what we needs now. bells and whistles can be added
later.
We need the wheels, steering, transmission and seats of the car to be built
first. Yes , we can add seat belts , Air conditioning etc later.
> 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: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
