> At least core level is easily pluggable in > Solr since forever but not the case for collection level!
Given the overlapping jargon, maybe this is a good topic to discuss synchronously in our next community meetup? I'll admit I'm pretty jumbled up on the terminology at this point haha. Are we talking about whether the actual logic for an endpoint is collection-aware? Or where the plugin is registered and configured? Assuming the latter....AFAIK "node" level (i.e. solr.xml) is just as pluggable as core-level (solrconfig.xml), if not more. Both places support defining request handlers, but only solr.xml will support adding jars going forward. On Tue, Dec 3, 2024 at 5:55 PM David Smiley <dsmi...@apache.org> wrote: > > 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 > >> > >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
