ZkMaintenanceUtils has the basic file manipulations between Zk and “someplace else”, although it’s pretty much file based. Does that have any bearing on the problem?
> On Aug 19, 2020, at 2:49 AM, Noble Paul <noble.p...@gmail.com> 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 <m...@mkr.io> 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 <noble.p...@gmail.com> 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 <m...@mkr.io> 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 <gerlowsk...@gmail.com> >>>>> 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 <noble.p...@gmail.com> 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: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > > -- > ----------------------------------------------------- > Noble Paul > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
