I think this is fine.I don't think we need a new concept of "config templates", we just need to make it clear that the configset used to create the collection is not modified by Solr, and that any change done via API only affects the single collection where the config command is issued.
I guess the schema API should start using something like configoverlay, or maybe persist the updated schema to this new path? Tomás On Fri, May 8, 2015 at 10:28 PM, Noble Paul <noble.p...@gmail.com> wrote: > 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 < > tomasflo...@gmail.com> 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 >
