I think this needs more discussion When a collection is created we should have two things
an immutable part and a mutable part for instance my collection name is "x" and it uses schemaless example conf I must now have two conf dirs configs/schemaless and configs/x all the mutable stuff goes to configs/x and config/schemaless remains immutable On Tue, May 12, 2015 at 2:23 AM, Tomás Fernández Löbbe < tomasflo...@gmail.com> wrote: > 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 >> > > -- ----------------------------------------------------- Noble Paul
