Apache Solr Documentation

6.5 Ref Guide (PDF Download)
Solr Tutorial
Solr Community Wiki

Older Versions of this Guide (PDF)

Ref Guide Topics

Meta-Documentation

*** As of June 2017, the latest Solr Ref Guide is located at https://lucene.apache.org/solr/guide ***

Please note comments on these pages have now been disabled for all users.

Skip to end of metadata
Go to start of metadata

The ConfigSets API enables you to create, delete, and otherwise manage ConfigSets. To use a ConfigSet created with this API as the configuration for a collection, use the Collections API.

This API can only be used with Solr running in SolrCloud mode. If you are not running Solr in SolrCloud mode but would still like to use shared configurations, please see the section Config Sets.

API Entry Points

The base URL for all API calls is http://<hostname>:<port>/solr.

/admin/configs?action=CREATE: create a ConfigSet, based on an existing ConfigSet
/admin/configs?action=DELETE: delete a ConfigSet
/admin/configs?action=LIST: list all ConfigSets

Create a ConfigSet

/admin/configs?action=CREATE&name=name&baseConfigSet=baseConfigSet

Create a ConfigSet, based on an existing ConfigSet.

Input

KeyTypeRequiredDefaultDescription
nameStringYes ConfigSet to be created
baseConfigSetStringYes ConfigSet to copy as a base
configSetProp.name=valueStringNo ConfigSet property from base to override

Output

Output Content

The output will include the status of the request. If the status is anything other than "success", an error message will explain why the request failed.

Examples

Input

Create a ConfigSet named 'myConfigSet' based on a 'predefinedTemplate' ConfigSet, overriding the immutable property to false.

Output

Delete a ConfigSet

/admin/configs?action=DELETE&name=name

Delete a ConfigSet

Input

Query Parameters

KeyTypeRequiredDefaultDescription
nameStringYes ConfigSet to be deleted

Output

Output Content

The output will include the status of the request. If the status is anything other than "success", an error message will explain why the request failed.

Examples

Input

Delete ConfigSet 'myConfigSet'

Output

List ConfigSets

/admin/configs?action=LIST

Fetch the names of the ConfigSets in the cluster.

Examples

Input

Output

  • No labels

4 Comments

  1. Gregory Chanan- Am I understanding correctly that this is an API to manage Config Sets, which are documented on the page Config Sets? If so, I think we should link the documentation more explicitly. Perhaps even merge the pages, but if we don't merge them, the pages should maybe live in the same place in the Ref Guide hierarchy. 

    Also, this feature will be released in 5.4, right?

  2. Cassandra Targett good question.  The nomenclature here is pretty confusing.

    The Config Sets page you linked is really about sharing "configurations", which are (Config, Schema, Properties) tuples, in non-cloud mode.  There's a good summary of the feature on Yonik's blog (http://yonik.com/solr-4-8-features/).

    The page here is about a "Config Sets" API for cloud mode.  Cloud mode could always share configurations – it's using the term "Config Set" in the literal sense of managing (Config, Schema, Properties) tuples for use with Solr collections.

    So, I think the options are either combine the pages and explain the differences between non-cloud and cloud mode or invent new nomenclature to differentiate the two.

     

    Also, yes, this feature will be released in 5.4.

    1. Thanks, Greg, for getting back to me - just able to get back to this now.

      I understand the distinction you're making, but I still feel like the functionality is related, even if it's not the same under the hood, and I think users will see it that way also. It's fine IMO to say the API can only be used with SolrCloud only (but it doesn't right now...), but I don't think we should try to make a really fine distinction between two features that are both ultimately about sharing configurations between collections.

      There are areas of Solr where behavior varies in SolrCloud mode vs. Standalone - I think that's OK, we just need to be upfront about it and relate the concepts where possible for those users who are maybe migrating from one approach to the other.

      I'll work on this a little bit and see what I can come up with.

  3. I vote for explaining the differences or even renaming the terms. The "configset" usage for examples (which is actually a copy, for good reasons) as compared with "configset" usage as a shared configuration in collection call as compared with this one. We've overload this term to the point of breaking, it feels like.