Some good food for thought here….    I hadn’t really dug quite so much into the 
specifics of the flow.

Do we think that having a generic “create” is making things simpler, or being 
more verbose and having create_core and create_collection suffice?   I guess I 
am wondering if there are good arguments for keeping create?   Mostly because 
when you run “bin/solr create -h”, we give the help output for the 
“create_collection” command…

One thought….  What if, when you run bin/solr create -h, we actually detect if 
you are in solrcloud mode and then delegate to either create_collection or 
create_core to decide the help output?



> On Jul 9, 2023, at 4:28 PM, Shawn Heisey <apa...@elyograg.org> wrote:
> 
> On 7/8/23 15:03, Ishan Chattopadhyaya wrote:
>> I'd rather we remove all three and encourage users to issue API commands
>> via curl.
>> I'm very much in favour of the scripts being used for only essential tasks,
>> but not for things where the API can be used. With the APIs being the
>> primary means to achieve tasks, users develop more familiarity when
>> starting out.
> 
> If configs are already uploaded to ZK, creating collections works with just 
> the API in cloud mode.  The bin/solr option will do the config upload for you 
> before creating the collection.
> 
> Out of the box, standalone mode can't create a core completely with the API.  
> If standalone mode is configured with configsets, then it can.  If we do keep 
> the bin/solr create option for standalone mode, I would like for it to be 
> able to detect what user Solr is running as and fail if the create command is 
> running under a different user.
> 
> There has been discussion about making future versions of Solr default to 
> cloud mode.  The API limitation for creating cores in standalone mode is one 
> thing in favor of that change.
> 
> I have been trying to think of ways we can automate the deployment of a 
> SolrCloud install, especially a high availability cluster that has three or 
> more nodes.  We have a solr service installer, I think we should also provide 
> a ZK service installer.  I don't think it would be a good plan to have that 
> whole idea use the embedded ZK, because with the embedded ZK, stopping or 
> restarting Solr also takes down one of the ZK nodes.
> 
> Even though I personally don't think of Windows as a viable platform for 
> running Solr, others do, so I think there should be service installers for 
> Windows.  Picking a service wrapper is something we could bikeshed forever 
> on.  Another thing to decide is whether to support 32-bit Windows or just 
> 64-bit.  I think it should just be 64-bit.
> 
> Thanks,
> Shawn
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
> 

_______________________
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | 
My Free/Busy <http://tinyurl.com/eric-cal>  
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 
<https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
    
This e-mail and all contents, including attachments, is considered to be 
Company Confidential unless explicitly stated otherwise, regardless of whether 
attachments are marked as such.

Reply via email to