I agree with you on the point that it causes confusion. My suggestion would be to have something called "config templates" and they are immutable . So , we don't need a configset API each collection have it's own conf folder .
So, when a collection is created we should go ahead and create a corresponding conf dir. Ideally, it should not copy over all configs from it's template. It should just store the configoverlay.json, params.json in the collection's conf directory and inherit the rest from the template On Sat, May 9, 2015 at 9:35 AM, Tomás Fernández Löbbe <[email protected] > wrote: > I think the concept of ConfigSets has become a bit confusing with the > Config APIs (I'm thinking in SolrCloud mode here). Solr requires that a > configset is pushed to ZooKeeper before creating a collection that uses it. > It supports multiple collections using the same configset, which I think is > great. You could also have a couple of configsets that no collection is > currently using (who knows, maybe one that was recently deprecated, or that > will be used soon, etc). This gives me the idea that configsets are a > separate entity than the collection, not just a collection's configuration. > > Config APIs allow you to operate on a collection to add handlers, change > settings, etc. The problem is that you are not really applying the changes > to the collection but to the complete configset. All collections using it > will get the changes, and all of them will be reloaded after a change. > > Shouldn't those APIs be at a different level/outside the collection? Maybe > a configset API? Or, maybe the configs (for example, the > configoverlay.json) should only apply to the collection where the API call > was made and not to other collections using the configset? > > Tomás > -- ----------------------------------------------------- Noble Paul
