I pushed up a fix for cloud.sh and tagged you (Gus) on it if you can double check.
Thanks for the feedback folks... > On Jul 18, 2023, at 10:33 AM, Gus Heck <gus.h...@gmail.com> wrote: > > * broken on main > > On Tue, Jul 18, 2023 at 10:33 AM Gus Heck <gus.h...@gmail.com> wrote: > >> Whatever we do here, just a note to test dev-tools/cloud.sh script. It's >> broken on master now from some seemingly related changes... >> >> Final NUM_NODES is 4 >> graph/solr-10.0.0-SNAPSHOT/bin/solr -c -s >> /Users/gus/projects/apache/solr/testing/graph/n1 -z >> localhost:2181/solr__Users_gus_projects_apache_solr_testing_graph -p 8981 >> -m 1g -a -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5001 >> -Dsolr.solrxml.location=zookeeper >> -Dsolr.log.dir=/Users/gus/projects/apache/solr/testing/graph/n1 >> -c is not a valid command! >> >> It's a pretty useful script since it is a one-touch recompile/redeploy of >> a local 4 node (or any other number of nodes) cluster that automatically >> has debugging enabled on all nodes. >> >> On Thu, Jul 13, 2023 at 4:58 PM David Smiley <david.w.smi...@gmail.com> >> wrote: >> >>>> So, thoughts maybe on eliminating create_core and create_collection? >>> Assuming we have the mode aware create command? >>> >>> +1 to eliminate though, simplifying to a smarter simpler "create" that is >>> aware of the mode. >>> >>> I don't think I like Houston's proposal of it giving instructions on >>> switching the modes; it seems to me like arbitrary help unrelated to >>> create. >>> >>> ~ David >>> >>> >>> On Thu, Jul 13, 2023 at 1:20 PM Eric Pugh < >>> ep...@opensourceconnections.com> >>> wrote: >>> >>>> 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. >>>> >>>> >>> >> >> >> -- >> http://www.needhamsoftware.com (work) >> http://www.the111shift.com (play) >> > > > -- > http://www.needhamsoftware.com (work) > http://www.the111shift.com (play) _______________________ 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.
