+1 Tomas. On Fri, May 15, 2015 at 12:40 PM Tomás Fernández Löbbe < tomasflo...@gmail.com> wrote:
> 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 >> > >
