So, sounds like you are in agreement that we should keep create, and make it smart about the mode you are in when we dump out the -h output. Plus, some informational hand holding.
So, thoughts maybe on eliminating create_core and create_collection? Assuming we have the mode aware create command? This would match up with the pattern of the delete command, which doesn’t have a delete_core or delete_collection variant ;-) > On Jul 13, 2023, at 10:33 AM, Houston Putman <houstonput...@gmail.com> wrote: > >> >> 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? > > > If we are going to have the command, this is absolutely what it should do. > And with -h, it can say that it is in <> mode, and that to create a > collection/core then please ensure you are using the right options. > (Basically giving them the instructions to switch to cloud/standalone if > they somehow are in the wrong mode) > > - Houston > > On Thu, Jul 13, 2023 at 8:03 AM Eric Pugh <ep...@opensourceconnections.com > <mailto:ep...@opensourceconnections.com>> > wrote: > >> 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. _______________________ 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.
