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 <dsmi...@apache.org> wrote: > 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 since forever but not the case for collection level! (unless you say > "Cluster Plugin" but sorry I don't want to be forced to call an API at > runtime when it should be solr.xml) > > On Tue, Dec 3, 2024 at 9:15 PM Jason Gerlowski <gerlowsk...@gmail.com> > wrote: > >> > 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 shouldn't have assumed. >> >> As you guys pointed out - there's not (currently) a strong precedent >> around whether core-registered APIs are aware of the larger cluster >> topology. Subactions within certain RH's enforce their own convention >> (e.g. All CollectionsHandler "actions" know about cluster topology, >> all CoreAdminHandler "actions" don't). But there's no overarching >> convention - so I wouldn't worry about running afoul of that one way >> or another. >> >> > Do we mean CoreAdminHandler (registered at node level), or do we >> > mean any handler registered *in* the core >> >> In terms of where APIs are registered - the main (only? am I missing >> something?) reason I know of to register an API at the core level is >> when you want the API to behave differently depending on the core. >> Different default params, only having the API for some cores, etc. >> >> So that'd be the first question I'd try to think through for the >> encryption case: is there a compelling need for encryption to only be >> available to certain cores? Or for its parameter defaults to vary >> core-by-core? >> >> Best, >> >> Jason >> >> On Tue, Dec 3, 2024 at 1:12 PM David Smiley <dsmi...@apache.org> wrote: >> > >> > 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/solrconfig.xml#L54 >> > There is ambiguity of the idea of a core or even collection "admin" >> > handler. Do we mean CoreAdminHandler (registered at node level), or do >> we >> > mean any handler registered *in* the core that we characterize as being >> > administrative in nature. >> > >> > Some of our handlers like SearchHandler are aware of the collection and >> > operate over the whole collection namespace. Most handlers (?) only >> know >> > about the core it's registered in, yet can nonetheless be contacted via >> a >> > core or collection request. >> > >> > >> > On Tue, Dec 3, 2024 at 3:36 PM Jason Gerlowski <gerlowsk...@gmail.com> >> > wrote: >> > >> > > 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 core. And then the "collection" level API >> > > would invoke the "core" API for each part of the collection, and do >> > > whatever other higher level logic is necessary (e.g. putting the >> > > collection into "read only" mode, sending messages to the overseer, >> > > etc.) >> > > >> > > This is a pretty common pattern among our collection operations. >> > > "Create collection" has a collection API to bootstrap the necessary ZK >> > > state and then uses a "core admin" API to create individual cores. >> > > "Backup" uses a collection API to put the collection into read-only >> > > mode, and then calls a "core admin" API for each core that needs to be >> > > backed up. etc. >> > > >> > > Hopefully that helps, unless I'm misunderstanding your question? >> > > >> > > Best, >> > > >> > > Jason >> > > >> > > On Wed, Nov 27, 2024 at 6:10 AM Bruno Roustant < >> bruno.roust...@gmail.com> >> > > wrote: >> > > > >> > > > Generally, where should go operations on a Collection? >> > > > At Collection admin level handler? >> > > > At Core level handler? >> > > > There are examples of both. >> > > > >> > > > I'm asking the question with the Solr encryption feature in mind (in >> > > > solr-sandbox). A client may want to encrypt all the indexes for a >> given >> > > > Collection. Which handler should receive the request? >> > > > A core level handler that would then distribute the request to all >> the >> > > > cores of the Collection across SolrCloud? Or a ClusterPlugin request >> > > > handler? >> > > > >> > > > Bruno >> > > >> > > --------------------------------------------------------------------- >> > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >> > > For additional commands, e-mail: dev-h...@solr.apache.org >> > > >> > > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >> For additional commands, e-mail: dev-h...@solr.apache.org >> >>
