Sure, can discuss at the next meetup. You can't define request handlers in solr.xml! Oh I wish this were possible! See https://issues.apache.org/jira/browse/SOLR-15782 and has a duplicate.
Any way, with /admin/encrypt, we're likely to just define in solrconfig.xml and make the handler recognize both modes via "distrib". On Wed, Dec 4, 2024 at 4:58 PM Jason Gerlowski <gerlowsk...@gmail.com> wrote: > > 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 > >
