I don't use ManagedResourceStorage, just the StorageIO interface and its implementations. The benefit is ZK AND filesystem support for WRITING configuration file updates. Otherwise I would have to come up with something like the common interface (StorageIO), its implementations for ZK and FS and the dispatching code (ManagedResourceStorage#newStorageIO) myself. I guess the LTR plugin had similar reasons to go that route.
On 19.08.20 08:49, Noble Paul wrote: > So, it's not very different from directly reading a file from ZK? > > what benefit do you get by using the ManagedResourceStorage? > > On Sun, Aug 16, 2020 at 7:08 PM Matthias Krueger <[email protected]> wrote: >> >> In a custom SolrRequestHandler#handleRequest something like this: >> >> final ManagedResourceStorage.StorageIO storageIO = >> ManagedResourceStorage.newStorageIO(core.getCoreDescriptor().getCollectionName(), >> resourceLoader, new NamedList<>()); >> >> And then using >> >> storageIO.openOutputStream(resourceName) >> >> to store some (well-known) resources. >> >> Matt >> >> >> On 15.08.20 11:38, Noble Paul wrote: >>>> I use MangedResource#StorageIO and its implementations as a convenient way >>>> to abstract away the underlying config storage when creating plugins that >>>> need to support both, SolrCloud and Solr Standalone. >>> Can you give us some more details on how you use it? >>> >>> On Sat, Aug 15, 2020 at 7:32 PM Noble Paul <[email protected]> wrote: >>>>> As authentication is plugged into the SolrDispatchFilter I would assume >>>>> that you would need to be authenticated to read/write Managed Resources >>>> I'm talking about the authorization plugins >>>> >>>> On Fri, Aug 14, 2020 at 10:20 PM Matthias Krueger <[email protected]> wrote: >>>>> As authentication is plugged into the SolrDispatchFilter I would assume >>>>> that you would need to be authenticated to read/write Managed Resources >>>>> but no authorization is checked (i.e. any authenticated user can >>>>> read/write them), correct? >>>>> >>>>> Anyway, I came across Managed Resources in at least two scenarios: >>>>> >>>>> The LTR plugin is using them for updating model/features. >>>>> I use MangedResource#StorageIO and its implementations as a convenient >>>>> way to abstract away the underlying config storage when creating plugins >>>>> that need to support both, SolrCloud and Solr Standalone. >>>>> >>>>> IMO an abstraction that allows distributing configuration (ML models, >>>>> configuration snippets, external file fields...) that exceeds the typical >>>>> ZK size limits to SolrCloud while also supporting Solr Standalone would >>>>> be nice to have. >>>>> >>>>> Matt >>>>> >>>>> >>>>> On 12.08.20 02:08, Noble Paul wrote: >>>>> >>>>> The end point is served by restlet. So, your rules are not going to be >>>>> honored. The rules work only if it is served by a Solr request handler >>>>> >>>>> On Wed, Aug 12, 2020, 12:46 AM Jason Gerlowski <[email protected]> >>>>> wrote: >>>>>> Hey Noble, >>>>>> >>>>>> Can you explain what you mean when you say it's not secured? Just for >>>>>> those of us who haven't been following the discussion so far? On the >>>>>> surface of things users taking advantage of our RuleBasedAuth plugin >>>>>> can secure this API like they can any other HTTP API. Or are you >>>>>> talking about some other security aspect here? >>>>>> >>>>>> Jason >>>>>> >>>>>> On Tue, Aug 11, 2020 at 9:55 AM Noble Paul <[email protected]> wrote: >>>>>>> Hi all, >>>>>>> The end-point for Managed resources is not secured. So it needs to be >>>>>>> fixed/eliminated. >>>>>>> >>>>>>> I would like to know what is the level of adoption for that feature >>>>>>> and if it is a critical feature for users. >>>>>>> >>>>>>> Another possibility is to offer a replacement for the feature using a >>>>>>> different API >>>>>>> >>>>>>> Your feedback will help us decide on what a potential solution should be >>>>>>> >>>>>>> -- >>>>>>> ----------------------------------------------------- >>>>>>> Noble Paul >>>> >>>> -- >>>> ----------------------------------------------------- >>>> Noble Paul >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
