Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
MIME-Version: 1.0
Date: Fri, 8 May 2015 21:05:31 -0700
Message-ID: 
 <CAMJgJxSXCHxDzJs5-C-pKFDEBQD6JbgxB=-Xp7u143eKmgp61w@mail.gmail.com>
Subject: Configsets and Config APIs in Solr
From: =?UTF-8?B?VG9tw6FzIEZlcm7DoW5kZXogTMO2YmJl?= <tomasflobbe@gmail.com>
To: dev@lucene.apache.org
Content-Type: multipart/alternative; boundary=047d7b6d8f947e739105159e416e

--047d7b6d8f947e739105159e416e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=C3=A1s

--047d7b6d8f947e739105159e416e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I think the concept of ConfigSets has become a bit co=
nfusing with the Config APIs (I&#39;m thinking in SolrCloud mode here). Sol=
r requires that a configset is pushed to ZooKeeper before creating a collec=
tion that uses it. It supports multiple collections using the same configse=
t, 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 de=
precated, or that will be used soon, etc). This gives me the idea that conf=
igsets are a separate entity than the collection, not just a collection&#39=
;s configuration.<br><br>Config APIs allow you to operate on a collection t=
o add handlers, change settings, etc. The problem is that you are not reall=
y 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 reloade=
d after a change.<br><br>Shouldn&#39;t those APIs be at a different level/o=
utside the collection? Maybe a configset API? Or, maybe the configs (for ex=
ample, the configoverlay.json) should only apply to the collection where th=
e API call was made and not to other collections using the configset?<br></=
div><div><br></div>Tom=C3=A1s<br></div>

--047d7b6d8f947e739105159e416e--