[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16099037#comment-16099037
]
Ishan Chattopadhyaya commented on SOLR-10272:
-
Hi Anshum, just minor ref guide documentation remains for a related issue,
SOLR-10574. I'll take it up tomorrow.
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16099005#comment-16099005
]
Anshum Gupta commented on SOLR-10272:
-
[~ichattopadhyaya] I think this is resolved, but can you confirm?
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16076609#comment-16076609
]
ASF subversion and git services commented on SOLR-10272:
Commit 04054fc524432388c7cea722b766815a950ca736 in lucene-solr's branch
refs/heads/branch_7_0 from [~ichattopadhyaya]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=04054fc ]
SOLR-10574, SOLR-10272: Refguide documentation for _default configset
(cherry picked from commit 112bdda)
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16076579#comment-16076579
]
ASF subversion and git services commented on SOLR-10272:
Commit d3acebcfe58320fa94517517caa1e3a537640a51 in lucene-solr's branch
refs/heads/branch_7x from [~ichattopadhyaya]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d3acebc ]
SOLR-10574, SOLR-10272: Refguide documentation for _default configset
(cherry picked from commit 112bdda)
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16076430#comment-16076430
]
ASF subversion and git services commented on SOLR-10272:
Commit 112bdda47eb9827e80500c767d09422efeb9b91e in lucene-solr's branch
refs/heads/master from [~ichattopadhyaya]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=112bdda ]
SOLR-10574, SOLR-10272: Refguide documentation for _default configset
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068569#comment-16068569
]
Ishan Chattopadhyaya commented on SOLR-10272:
-
Thanks Steve. I think it was the case of Solaris kernel returning list of files
in a different order.
Shalin, your suggestion is implemented; thanks! Now, *if a unit test doesn't
specify a configset name while creating a collection, it will use the _default
configset*, not conf1. Also, *any change to the _default configset would need
to go into two places*: the user's _default configset, i.e.
server/solr/configsets/_default, and the _default configset in
solr/core/test-files/_default.*
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068560#comment-16068560
]
ASF subversion and git services commented on SOLR-10272:
Commit 46bfd9cf7e9da99e936fe986af88f4ab47d7fe33 in lucene-solr's branch
refs/heads/master from [~ichattopadhyaya]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=46bfd9c ]
SOLR-10272: Fix for test failure, while comparing directory contents of
_default configsets
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068406#comment-16068406
]
David Smiley commented on SOLR-10272:
-
Wow that's an insightful catch [~steve_rowe]!
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068402#comment-16068402
]
Steve Rowe commented on SOLR-10272:
---
Policeman Jenkins failure
[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1408/] - doesn't
reproduce for me on Linux, but I suspect the Solaris platform is relevant here,
and that the failing directory comparison is depending on a sort that's not
stable across platforms, since the directory contents are the same, just in a
different order:
{noformat}
Checking out Revision c9c0121d9399ff0009c51d6a32632dd0962e8c8f
(refs/remotes/origin/master)
[...]
[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestConfigSetsAPI
-Dtests.method=testUserAndTestDefaultConfigsetsAreSame
-Dtests.seed=DBE6E9A12E3D770 -Dtests.slow=true -Dtests.locale=zh
-Dtests.timezone=Africa/Sao_Tome -Dtests.asserts=true
-Dtests.file.encoding=ISO-8859-1
[junit4] FAILURE 2.02s J1 |
TestConfigSetsAPI.testUserAndTestDefaultConfigsetsAreSame <<<
[junit4]> Throwable #1: org.junit.ComparisonFailure: Mismatch in files
expected:<[[lang, elevate.xml, currency.xml, managed-schema, params.json,
protwords.txt, stopwords.txt, synonyms.txt, solrconfig.xml]]> but
was:<[[params.json, solrconfig.xml, lang, currency.xml, stopwords.txt,
elevate.xml, protwords.txt, managed-schema, synonyms.txt]]>
[junit4]>at
__randomizedtesting.SeedInfo.seed([DBE6E9A12E3D770:72C37467A4C75D3]:0)
[junit4]>at
org.apache.solr.cloud.TestConfigSetsAPI$1.preVisitDirectory(TestConfigSetsAPI.java:747)
[junit4]>at
org.apache.solr.cloud.TestConfigSetsAPI$1.preVisitDirectory(TestConfigSetsAPI.java:741)
[junit4]>at java.nio.file.Files.walkFileTree(Files.java:2677)
[junit4]>at java.nio.file.Files.walkFileTree(Files.java:2742)
[junit4]>at
org.apache.solr.cloud.TestConfigSetsAPI.compareDirectories(TestConfigSetsAPI.java:741)
[junit4]>at
org.apache.solr.cloud.TestConfigSetsAPI.testUserAndTestDefaultConfigsetsAreSame(TestConfigSetsAPI.java:732)
[junit4]>at java.lang.Thread.run(Thread.java:748)
[junit4] 2> NOTE: leaving temporary files on disk at:
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J1/temp/solr.cloud.TestConfigSetsAPI_DBE6E9A12E3D770-001
[junit4] 2> Jun 29, 2017 11:31:15 AM
com.carrotsearch.randomizedtesting.ThreadLeakControl checkThreadLeaks
[junit4] 2> WARNING: Will linger awaiting termination of 1 leaked
thread(s).
[junit4] 2> NOTE: test params are: codec=Lucene70,
sim=RandomSimilarity(queryNorm=false): {}, locale=zh, timezone=Africa/Sao_Tome
[junit4] 2> NOTE: SunOS 5.11 amd64/Oracle Corporation 1.8.0_131
(64-bit)/cpus=3,threads=1,free=176703120,total=518979584
[junit4] 2> NOTE: All tests run in this JVM: [TestQueryUtils,
MoveReplicaTest, EchoParamsTest, SparseHLLTest, TestPayloadScoreQParserPlugin,
TestLegacyFieldCache, SimpleMLTQParserTest, TestLockTree, V2StandaloneTest,
TestPushWriter, TestDynamicFieldCollectionResource, BasicAuthStandaloneTest,
TestPerFieldSimilarity, TestFieldCollectionResource,
OverseerModifyCollectionTest, TestPostingsSolrHighlighter,
TestMultiValuedNumericRangeQuery, TestUseDocValuesAsStored, TestStressLucene,
TestInPlaceUpdatesStandalone, SolrGraphiteReporterTest,
DistributedFacetPivotSmallTest, TestChildDocTransformer, TestFastWriter,
TestSolrJ, TestDistributedGrouping, TestDynamicLoading,
DistribDocExpirationUpdateProcessorTest, FieldMutatingUpdateProcessorTest,
SolrPluginUtilsTest, TestFiltering, TestSizeLimitedDistributedMap,
SolrCmdDistributorTest, TestSolrConfigHandlerCloud,
DocumentAnalysisRequestHandlerTest, HdfsTlogReplayBufferedWhileIndexingTest,
TestCryptoKeys, DirectSolrSpellCheckerTest, TestPolicyCloud,
LukeRequestHandlerTest, TestReplicaProperties, BasicZkTest,
SolrCoreCheckLockOnStartupTest, ParsingFieldUpdateProcessorsTest,
DistributedQueryComponentCustomSortTest, SpellCheckCollatorTest,
DistributedFacetPivotLongTailTest, SolrIndexConfigTest,
TlogReplayBufferedWhileIndexingTest, TestRandomCollapseQParserPlugin,
TestRequestStatusCollectionAPI, CurrencyFieldTypeTest,
TestExclusionRuleCollectionAccess, HdfsSyncSliceTest,
HdfsChaosMonkeySafeLeaderTest, ReplicationFactorTest, TestAnalyzedSuggestions,
TermsComponentTest, TestWordDelimiterFilterFactory,
ClassificationUpdateProcessorTest, TestManagedSynonymGraphFilterFactory,
FileBasedSpellCheckerTest, TestSchemaNameResource,
TestSlowCompositeReaderWrapper, SolrCloudExampleTest, TestInitQParser,
CachingDirectoryFactoryTest, TestTolerantUpdateProcessorCloud,
TestCloudRecovery, SolrShardReporterTest, TestRecovery, BlockCacheTest,
TestInfoStreamLogging, TestConfigSetsAPIExclusivity, TestSolrFieldCacheBean,
FullSolrCloudDistribCmdsTest, TestValueSourceCache,
OpenExchangeRatesOrgProviderTes
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16067754#comment-16067754
]
Ishan Chattopadhyaya commented on SOLR-10272:
-
Leaving this issue open for adding documentation changes (ref guide), and will
also do more manual testing across GNU/Linux and Windows over the next few days.
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16067750#comment-16067750
]
ASF subversion and git services commented on SOLR-10272:
Commit 85069cacf40e757b3eb4d4d211b1783faf800bc5 in lucene-solr's branch
refs/heads/master from [~ichattopadhyaya]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=85069cac ]
SOLR-10272: Adding user _default configset to test-files, fixing solr &
solr.cmd script bugs
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16066073#comment-16066073
]
Ishan Chattopadhyaya commented on SOLR-10272:
-
It seems bin/solr's create_core for standalone Solr is not working due to this.
There's no unit test for this at the moment.
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065071#comment-16065071
]
ASF subversion and git services commented on SOLR-10272:
Commit ab319eab2427e0da6979c78cd391de2c49da1259 in lucene-solr's branch
refs/heads/master from [~ichattopadhyaya]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ab319ea ]
SOLR-10272: Fix precommit (the correct way)
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16064813#comment-16064813
]
Shalin Shekhar Mangar commented on SOLR-10272:
--
I can see why a bogus _default configset for tests would have been useful
during development to identify tests that were not specifying configset names
already during collection creation and switch them to use "conf" or "conf1"
configsets explicitly. But I don't see its usefulness once this exercise is
complete.
Since our collection creation API now uses _default configset by default, our
tests should also do the same if no explicit configset name is specified. The
_default for tests should be identical to the ones that users will use. This
ensures that if a functionality is tested using the _default configset, it will
actually work in the hands of our users. If we need to duplicate _default in
two places to achieve this, then we should add a test to assert that both are
same. This only really affects new tests since I am assuming existing ones have
been cut over to "conf" already.
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16064782#comment-16064782
]
ASF subversion and git services commented on SOLR-10272:
Commit e6f48ca6bcea8962282b82826709fbfd3c2fa6bb in lucene-solr's branch
refs/heads/master from [~ichattopadhyaya]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e6f48ca ]
SOLR-10272: More detailed error message, explaining what to do
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16064780#comment-16064780
]
Ishan Chattopadhyaya commented on SOLR-10272:
-
Just a note on errors like: "This is the _default configset, which is designed
to throw error upon collection creation."
Almost all tests either use the "conf1" configset (which is uploaded initially)
or explicitly upload a configset and use that. However, almost all CREATE
commands did not specify the configset name. After this change, if configset
name is not specified, the _default configset would be used. Hence, *if you see
this error*, it means you inadvertently used a _default configset and you
should modify your test to explicitly specify your configset name while
creating a collection (usually this is called "conf" or "conf1"). The _default
configset available to the test-framework is a bogus one that deliberately
throws that error so that no one inadvertently uses it and instead explicitly
specifies the required configset name.
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16064673#comment-16064673
]
Ishan Chattopadhyaya commented on SOLR-10272:
-
Apologies for the failure. I've committed a fix to suppress the forbidden
method call, since it is for a test.
I am looking to move that method call to somewhere in the test-framework (by
figuring out the _default configdir in the tests, possibly using that forbidden
method call, and setting the appropriate sysprop from there) so that I can take
the suppression there instead of doing it in ZkController.
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16064672#comment-16064672
]
ASF subversion and git services commented on SOLR-10272:
Commit e4d0bb7dc45905b6ab231b940adecd5c5a39eb8e in lucene-solr's branch
refs/heads/master from [~ichattopadhyaya]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e4d0bb7 ]
SOLR-10272: Fixing precommit
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16064631#comment-16064631
]
Ishan Chattopadhyaya commented on SOLR-10272:
-
Thanks Alan, I'll fix.
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16064508#comment-16064508
]
Alan Woodward commented on SOLR-10272:
--
Hey Ishan, I think this has broken precommit? ZkController is using the
context class loader, which is not permitted by forbidden-apis.
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16064222#comment-16064222
]
Ishan Chattopadhyaya commented on SOLR-10272:
-
Leaving this open for documentation changes (ref guide, as well as, possibly,
bin/solr help instructions).
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16064208#comment-16064208
]
ASF subversion and git services commented on SOLR-10272:
Commit c66a8d9fda97f24216e561df410f3eb351b5c934 in lucene-solr's branch
refs/heads/master from [~ichattopadhyaya]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c66a8d9 ]
SOLR-10272: Reverting a mistakenly deleted file
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16064204#comment-16064204
]
ASF subversion and git services commented on SOLR-10272:
Commit ee572b052a9163d2884bad9e53cef52fc937bcbb in lucene-solr's branch
refs/heads/master from [~ichattopadhyaya]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ee572b0 ]
SOLR-10272: Use _default config set if config name is not specified with CREATE
collection
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16063836#comment-16063836
]
Ishan Chattopadhyaya commented on SOLR-10272:
-
I've updated the patch here, and created a branch: jira/solr-10272.
https://github.com/apache/lucene-solr/tree/jira/solr-10272
This now uses the _default configset (SOLR-10574), which is bootstrapped upon
Solr's startup.
A few more cleanups related to the "conf1" configset in unit tests are
remaining, and then planning to commit soon.
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16023702#comment-16023702
]
David Smiley commented on SOLR-10272:
-
That sounds good too Cassandra. That's complementary to this issue; I do like
what this issue (title) proposes... I just don't want a default that
automatically manipulates the schema based on new data. That should be chosen
explicitly, not accidentally.
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16023620#comment-16023620
]
Cassandra Targett commented on SOLR-10272:
--
I know this issue is about making the configName param optional, but what if we
just pre-loaded all three examples at initial startup? It wouldn't remove the
requirement that the configName param is specified, but it removes the need to
pre-upload it. The CLI already requires you to choose one, but API users could
use the Config API's LIST command to get a list of them, and UI users would see
all of them in the UI to choose from.
Just throwing it out there - IMO it could accomplish a lot of the ease-of-use
goals behind the idea for this issue, but doesn't require us to redo any
examples or come up with odd names (like "_default") that aren't used anywhere
else in the software.
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15987353#comment-15987353
]
Jan Høydahl commented on SOLR-10272:
bq. When Solr starts up, the datadriven configset is uploaded to ZK, called
"_default".
Are we sure we want to upload a new {{_default}} thingie? Default does not
really say anything, just like the old {{collection1}} default was not a great
idea. The bin/solr script uploads a config to a user-named config - or if no
name given - to a new config with the same name as the collection. Should not
the Collection API behaviour be something like that?
bq. Then in SOLR-10574 I think we can discuss modifying this config, perhaps
making a data-driven option toggle-able instead of fundamental to the config.
That could work. Perhaps write in CHANGES that the default is to be considered
experimental for the next few releases...
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986661#comment-15986661
]
David Smiley commented on SOLR-10272:
-
The default at the CLI doesn't matter much to me because there are other
options at the CLI -- particularly "basic_configs". That isn't the case for
this feature -- a baked in SolrCloud default. So the default choice is way
more important here.
bq. Do you think we should decide upon the best choice for the default
configset first, before making whatever is the default be used by the
Collections API?
Unless the data-driven (auto schema modifications) can be easily disabled, then
yes.
If at this stage (this issue) we simply want to pick an existing config and not
make changes to any particular config, then I think the only suitable choice is
"basic_configs".
Then in SOLR-10574 I think we can discuss modifying this config, perhaps
_making a data-driven option toggle-able instead of fundamental to the config_.
AFAIK that wouldn't involve new code; just some configuration in such a way
that users can toggle easily -- perhaps by setting {{update.chain}} with the
request parameters API:
https://cwiki.apache.org/confluence/display/solr/Request+Parameters+API
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986480#comment-15986480
]
Ishan Chattopadhyaya commented on SOLR-10272:
-
As far as I understand, we made a conscious choice of making the
data_driven_schema_configs as the default when using the script. This issue
just delegates the selection of the default configset to the Collections API
instead of the script.
My thought was to first get the default configset to be used by the Collections
API, and then (in another issue) decide upon which configset is best suited for
being the default -- I agree that data_driven_schema_configs is not the best
choice. Do you think we should decide upon the best choice for the default
configset first, before making whatever is the default be used by the
Collections API? I can open another JIRA, where we can discuss the
possibilities?
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986446#comment-15986446
]
David Smiley commented on SOLR-10272:
-
I understand that bin/solr might default to use a "data driven" config but it's
easy enough to be explicit at the CLI and make another choice. It's very
depressing and sad to me to hear that this very JIRA issue is going to make
that particular configuration so prominent that it's the only one that will be
in Solr by default already there. If users (you, me, us, everyone) are to use
the feature you are working on here -- relying on a config already in Solr --
then what step do we do to turn the data-driven schema aspect of the config
off? Unless I'm doing a demo or POC, I will _always_ be performing this step.
If there is no step (short of outright replacing solrconfig.xml in ZK), then I
feel I need to -1 this change.
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Ishan Chattopadhyaya
> Attachments: SOLR-10272.patch, SOLR-10272.patch.gz,
> SOLR-10272.patch.gz, SOLR-10272.patch.gz
>
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15973004#comment-15973004
]
Ishan Chattopadhyaya commented on SOLR-10272:
-
I agree with you! I just want to be clear that this issue is about the
collection API using the default, and not about what the default should be.
In this issue, I just want to maintain current behaviour as in bin/solr: if you
create a collection using the script, without a configset, the configset used
is the data driven schema.
However, we could discuss and do the cool parts in another issue (esp. the
"training mode" schema generation and other ideas).
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15972993#comment-15972993
]
David Smiley commented on SOLR-10272:
-
Thanks for doing this [~ichattopadhyaya]; overall your plan looks great.
But I'm concerned about the choice of the "data driven" configset being chosen
as the default. The "data driven" feature is really only appropriate for
fooling around; we shouldn't elevate it's status as the new default. I recall
a conversation I had with [~noble.paul] and [~varunthacker] in person in
February and, I could be mistaken, but I think the 3 of us liked the idea of a
default configset that could be used that had the
"add-unknown-fields-to-the-schema" URP chain configured and available but not
registered by default by /update. For example, perhaps a different
/update/createSchema or something like that? Heck; it could even be an URP
chain that deliberately has no RunUpdateProcessorFactory if it's job is purely
to create the schema for you. I think [~hossman] had a similar idea discussed
with us all at the last Lucene/Solr Revolution. I loved the idea!
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15972956#comment-15972956
]
Ishan Chattopadhyaya commented on SOLR-10272:
-
I'm planning the following:
1. When Solr starts up, the datadriven configset is uploaded to ZK, called
"_default".
2. When Collection API's CREATE command is called without any configset name,
it copies over [0] "_default" configset to, say, "collection1" and creates a
collection.
[0] -
https://cwiki.apache.org/confluence/display/solr/ConfigSets+API#ConfigSetsAPI-create
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15924579#comment-15924579
]
Erick Erickson commented on SOLR-10272:
---
bq: Also, the Collection API's CREATE command should optionally accept a
configset (zipped),
Be careful here. See SOLR-5287, particularly Uwe's comments on 3-Nov-13 and
following on that JIRA. Allowing someone to upload arbitrary files with
XML/XSL has security implications. For the functionality you mention, the
zipped files could be anything. I can't claim to understand the details, but
before putting the work into it we should check this out.
Stefan and I had this _brilliant_ idea to allow editing schema and config from
the UI that...er...wasn't so brilliant.
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15924476#comment-15924476
]
Ishan Chattopadhyaya commented on SOLR-10272:
-
bq. Could the bootstrapping of the default/generic configSet be done by
collection API instead of start script? Then also our unit tests will trigger
the same code path as a user starting Solr by start script.
+1, that's one of the motivations behind my previous comment.
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15924460#comment-15924460
]
Ishan Chattopadhyaya commented on SOLR-10272:
-
>From a user's point of view, the Collections API's CREATE command should be
>able to create a collection without specifying a configset - in that case, the
>basicconfigset could be used by default (whether this basicconfigset was
>pre-loaded when Solr started up, or the Solr process itself uploaded it from
>its install directory into ZK is an implementation detail).
Also, the Collection API's CREATE command should optionally accept a configset
(zipped), and it should create a collection based on that configset.
(Internally, it can use SOLR-6736, but that's an implementation detail.)
Also, the user could first upload a configset (using SOLR-6736) and then
specify the configName while creating a collection.
bq. I wouldn't want to lose the capability from the bin/solr script
The functionality of being able to upload a config by using bin/solr would
stay. But, the way collection creation happens now using the bin/solr script,
could change to leverage the Solr endpoints directly, instead of needing to
upload a configset to ZK directly.
bq. an additional collections API "BOOTSTRAPCONFIG" or something I don't see
why not. Maybe a separate JIRA?
I think SOLR-6736's configset API's upload functionality can do this.
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15924440#comment-15924440
]
Erick Erickson commented on SOLR-10272:
---
Jan:
I wouldn't want to lose the capability from the bin/solr script, but if you're
thinking of an additional collections API "BOOTSTRAPCONFIG" or something I
don't see why not.
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15923785#comment-15923785
]
Jan Høydahl commented on SOLR-10272:
Could the bootstrapping of the default/generic configSet be done by collection
API instead of start script? Then also our unit tests will trigger the same
code path as a user starting Solr by start script.
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15922798#comment-15922798
]
Varun Thacker commented on SOLR-10272:
--
Hi Erick,
Okay I should have been more descriptive here. Today the start script works
like this when we create a collection
{code}
~/solr-6.4.2$ ./bin/solr create -c test
Connecting to ZooKeeper at localhost:9983 ...
INFO - 2017-03-13 12:28:04.069;
org.apache.solr.client.solrj.impl.ZkClientClusterStateProvider; Cluster at
localhost:9983 ready
Uploading
/Users/varunthacker/solr-6.4.2/server/solr/configsets/data_driven_schema_configs/conf
for config test to ZooKeeper at localhost:9983
Creating new collection 'test' using command:
http://localhost:7574/solr/admin/collections?action=CREATE&name=test&numShards=1&replicationFactor=1&maxShardsPerNode=1&collection.configName=test
{
"responseHeader":{
"status":0,
"QTime":2555},
"success":{"192.168.0.4:7574_solr":{
"responseHeader":{
"status":0,
"QTime":1425},
"core":"test_shard1_replica1"}}}
{code}
Given that this Jira adds a default configset and uses that if no
"collection.configName" is present , we can remove this logic from the create
command as this will be done automatically
{code}
Connecting to ZooKeeper at localhost:9983 ...
INFO - 2017-03-13 12:28:04.069;
org.apache.solr.client.solrj.impl.ZkClientClusterStateProvider; Cluster at
localhost:9983 ready
Uploading
/Users/varunthacker/solr-6.4.2/server/solr/configsets/data_driven_schema_configs/conf
for config test to ZooKeeper at localhost:9983
{code}
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10272) Use a default configset and make the configName parameter optional.
[
https://issues.apache.org/jira/browse/SOLR-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15922779#comment-15922779
]
Erick Erickson commented on SOLR-10272:
---
Not quite sure what you mean by <3>. Change _which_ parts of that script?
> zk upconfig|downconfig?
> create_collection?
> example startup?
I really don't want to remove any of those. I often use the example startup to
specify a custom configset 'cause it's easy, I don't have to do the separate
step of uploading a configset.
The first two seem to need to be kept for advanced users.
> Use a default configset and make the configName parameter optional.
> ---
>
> Key: SOLR-10272
> URL: https://issues.apache.org/jira/browse/SOLR-10272
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>
> This Jira's motivation is to improve the creating a collection experience
> better for users.
> To create a collection we need to specify a configName that needs to be
> present in ZK. When a new user is starting Solr why should he worry about
> having to know about configsets before he can can create a collection.
> When you create a collection using "bin/solr create" the script uploads a
> configset and references it. This is great. We should extend this idea to API
> users as well.
> So here is the rough outline of what I think we can do here:
> 1. When you start solr , the bin script checks to see if
> "/configs/_baseConfigSet" znode is present . If not it uploads the
> "basic_configs".
> We can discuss if its the "basic_configs" or something other default config
> set.
> Also we can discuss the name for "/_baseConfigSet". Moving on though
> 2. When a user creates a collection from the API
> {{admin/collections?action=CREATE&name=gettingstarted}} here is what we do :
> Use https://cwiki.apache.org/confluence/display/solr/ConfigSets+API to copy
> over the default config set to a configset with the name of the collection
> specified.
> collection.configName can truly be an optional parameter. If its specified we
> don't need to do this step.
> 3. Have the bin scripts use this and remove the logic built in there to do
> the same thing.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
