>
> 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>
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.
>
>

Reply via email to