You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Noble Paul (Jira)" <ji...@apache.org> on 2019/09/20 12:44:00 UTC

[jira] [Comment Edited] (SOLR-13661) A package management system for Solr

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

Noble Paul edited comment on SOLR-13661 at 9/20/19 12:43 PM:
-------------------------------------------------------------

The reason why we built hot deployment was that Solr was unstable when we end up restarting a 1000 node cluster and we ended up losing shards and our cluster suffered downtime as well. This was holding up our deployment of new features. So, this is not a "cool" feature for us, it was a deal breaker

[~dsmiley] I went through jan's work and I had raised my concerns of its usability and other issues. So, if I'm building something I should atleast address those concerns.
Jans plugin package mechanism required users to build their custom packages. In this case you could deploy your existing jars without any modification. You don't have to do anything special

At this point , I would love to focus our eyes on the design and implementation of this particular feature, instead of discussing why something else was not adopted. We should discuss "what" and "why" instead of "how". 

Let's understand that this is not our hobby. It's a job. We are all able to do this because somebody is funding the development .When somebody is funding the development, they will have certain requirements and all their requirements need to be met. I'm sure every org works like that. Salesforce, Bloomberg, Apple , Lucidworks and all the big contributors are building big features to satisfy their businesses.




was (Author: noble.paul):
The reason why we built hot deployment was that Solr was unstable when we end up restarting a 1000 node cluster and we ended up losing shards and our cluster suffered downtime as well. This was holding up our deployment of new features. So, this is not a "cool" feature for us, it was a deal breaker

[~dsmiley] I went through jan's work and I had raised my concerns of its usability and other issues. So, if I'm building something I should atleast address those concerns.
Jans plugin package mechanism required users to build their custom packages. In this case you could deploy your existing jars without any modification. You don't have to do anything special

At this point , I would love to focus our eyes on the design and implementation of this particular feature, instead of discussing why something else was not adopted. We should discuss "what" and "why" instead of "how". 



> 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
>            Priority: Major
>              Labels: package
>
> Solr needs a unified cohesive package management system so that users can deploy/redeploy plugins in a safe manner. This is an umbrella issue to eventually build that solution



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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