* 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)
