BTW when I speak of "core level", it's core/configSet since the
configuration applies to all cores of that type and they literally run in
the context of a core.
On Tue, Dec 3, 2024 at 11:53 PM David Smiley wrote:
> No encryption isn't different from one core to the next but when you tell
> a col
No encryption isn't different from one core to the next but when you tell a
collection to encrypt itself, you expect all cores to participate in this.
I don't think of this as being a factor in choosing solrconfig.xml
registration vs Collection API. At least core level is easily pluggable in
Solr
> There is ambiguity of the idea of a core or even collection "admin"
> handler.
Ah, I see. I've always used the terms "core admin" and "collection
admin" to refer to the specific endpoints exposed at those paths (i.e.
/admin/cores and /admin/collections). But you're right that it's
ambiguous - I
When Bruno said a "Core level handler", he meant a RequestHandler
registered in solrconfig.xml and thus accessible as
/solr/coreName/admin/encrypt as seen here:
https://github.com/apache/solr-sandbox/blob/4e1819ff8a3758becca19bf337ecd1b352dba805/encryption/src/test/resources/configs/collection1/sol
I think the most common way we do stuff like this is two have an API
at both the "core" and "collection" levels, with the "collection" API
being used to orchestrate N calls to the lower-level "core" API.
Using encryption as the example: the "core"-level API might manage the
encryption of a single
