SOLR-17302: Convert remaining filestore APIs to JAX-RS#2532
SOLR-17302: Convert remaining filestore APIs to JAX-RS#2532gerlowskija merged 10 commits intoapache:mainfrom
Conversation
One small step in aligning all filestore APIs on the '/cluster/files/' HTTP path.
Plausibly works on the server-side, though the generated SolrRequest implementation will almost surely NOT work. Finally, this commit changes the path for these APIs to be /cluster/files (instead of the previously used `/node/files`). I need to think through the backcompat implications of this a bit more thoroughly. I probably need a version of these APIs also available at the original path.
TestDistribFileStore passes; ship it.
epugh
left a comment
There was a problem hiding this comment.
Great work here moving things forward... Out of curisoity, do the existing tests then cover this all with no change? amazing?
| /** | ||
| * V2 APIs for fetching filestore files, syncing them across nodes, or fetching related metadata. | ||
| * | ||
| * @see MergeIndexesRequestBody |
There was a problem hiding this comment.
It's not doing anything "magic" for our code-generation, etc. - it's just something the Javadoc syntax supports.
And in this case, it's there by copy/paste error 😛 Thanks for pointing it out haha!
| METADATA | ||
| } | ||
|
|
||
| interface FileDetails extends MapWriter { |
| this.fileStore = fileStore; | ||
| } | ||
|
|
||
| // TODO - this single "get" operation actually supports several different chunks of functionality: |
There was a problem hiding this comment.
I wish we had JIRA's that referenced the "Todo" work...
There was a problem hiding this comment.
It would be nice. I think the lack of a JIRA reference in this case reflects my own uncertainty about how to proceed.
In theory SOLR-17302 is already sortof meant to cover this type of "cosmetic improvement" change. That's how many of our v2 tickets are setup - to cover both JAX-RS conversion and "cosmetic changes" all in one.
But in practice I'm not sure whether it's safe/responsible to modify the appearance of these particular v2 endpoints. They're technically "experimental", but they're the only way to access the filestore - there's no v1 equivalent that we can recommend to folks.
I'm going to start a discussion on SOLR-17302 about this, which will hopefully draw some more eyes and get us some clarity on how to proceed.
There was a problem hiding this comment.
Actually - small correction - apparently when I wrote up SOLR-17302 I worded it in such a way that it only covers migration to JAX-RS.
So there's no ticket (yet) for breaking up this API into more manageable chunks. I'll file a separate ticket for this and reference it here (and in the code) when its ready.
There was a problem hiding this comment.
| if (path == null) { | ||
| path = ""; | ||
| } | ||
| FileStore.FileType typ = fileStore.getType(path, false); |
There was a problem hiding this comment.
This is something that carried over from the existing code, and I'm leery of getting sucked into larger improvements to that code. There's a lot that could be done there.
But I can change it since it's a small modification.
| } else { // User wants to get the "raw" file | ||
| // TODO Should we be trying to json-ify otherwise "raw" files in this way? It seems like a | ||
| // pretty sketchy idea, esp. for code with very little test coverage. Consider removing | ||
| final var pathCopy2 = path; |
There was a problem hiding this comment.
This is something that carried over from the existing code, and I'm leery of getting sucked into larger improvements to that code. There's a lot that could be done there.
But I can change it since it's a small modification.
| req.setParams(SolrParams.wrapDefaults(solrParams, req.getParams())); | ||
| rsp.add( | ||
| CONTENT, | ||
| (SolrCore.RawWriter) |
| } else if (obj != null && (obj instanceof SolrCore.RawWriter)) { | ||
| final var rawWriter = (SolrCore.RawWriter) obj; | ||
| rawWriter.write(out); | ||
| if (rawWriter instanceof Closeable) ((Closeable) rawWriter).close(); |
There was a problem hiding this comment.
This is something that carried over from existing code.
I've agreed to a few variable renames above in code that preexists this PR, but I'll probably skip this change. IMO this code could use lots of reformatting/restructuring attention, but we need to draw the line somewhere.
|
Looks like |
|
The PackageToolTest failure actually surfaced an interesting little v2 API bug - the v2 authz code wasn't properly detecting when a request had been authenticated as the special PKI principal '$'. This PR now fixes that bug as well, using code similar to what we use in the v1 case. With this fixed I'm marking the PR as "ready for review"! |
Gnarly little fix there! |
This migrates the remainder of Solr's "filestore" APIs to the JAX-RS framework. No cosmetic changes were made in the process, with the small exception of folding the internal "local delete" functionality into the existing delete API using a new `localDelete` boolean query param.
This migrates the remainder of Solr's "filestore" APIs to the JAX-RS framework. No cosmetic changes were made in the process, with the small exception of folding the internal "local delete" functionality into the existing delete API using a new `localDelete` boolean query param.
https://issues.apache.org/jira/browse/SOLR-17302
Description
PR #2470 converted a few file store APIs (those available under the
/api/clusterpath) to JAX-RS. But the PR didn't touch several other APIs, which still needed JAX-RS conversion, including:Solution
This PR migrates the remaining filestore APIs to JAX-RS. This migration is largely done "as-is", avoiding any cosmetic changes to the APIs. IMO cosmetic improvements are much needed here (see SOLR-17302 for more details), but I've skipped those here because despite being "experimental" v2 APIs, these APIs are the only way to access Solr's filestore, so we might need to be a little more careful about changes. I've started a discussion around this in SOLR-17302 for a hopefully wider audience to chime in.
One exception to this is the internal "local-delete" API, which is used internally by Solr. It's not documented, nor does it have any use from an end-user perspective, so changing this API seemed a little more clear-cut. This functionality can now be triggered via a
localDeleteparameter on the existing filestore delete API (e.g.DELETE /cluster/files/somePath.txt?localDelete=true)We utilize "RawResponseWriter" for serializing the raw file data when fetching filestore files, to match the approach taken by the existing ZooKeeperReadAPI code.
Tests
Existing filestore tests continue to pass, as this is mostly a refactor. Additional unit tests in V2ApiUtils and elsewhere.
Checklist
Please review the following and check all that apply:
mainbranch../gradlew check.