I agree about differentiating the mutable part (configoverlay, generated schema, etc) and the immutable (the configset) , but I think it would be better if the mutable part is placed under /collections/x/..., otherwise "/configs" would have a mix of ConfigSets and collection-specific configuration.
On Fri, May 15, 2015 at 6:38 AM, Noble Paul <noble.p...@gmail.com> wrote: > 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 >
