[
https://issues.apache.org/jira/browse/SOLR-5287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated SOLR-5287:
---------------------------------
Attachment: SOLR-5287.patch
Well, this is scary. I hacked together a butchery of ShowFileRequestHandler (so
far only local no ZK support).
The most work was refactoring this a bit so I could re-use some of the work
already there.
But it...works. Even updating files in subdirectories of conf, e.g. velocity.
It turns out that ShowFileRequestHandler _already_ lists the contents of a
directory if it is a directory. So something like:
http://localhost:8983/solr/collection1/admin/file?file=velocity
will list the contents of the conf/velocity, and
http://localhost:8983/solr/collection1/admin/file
will list the contents of the conf directory itself.
So, adding a param "op=write" and "file=whatever" and posting a stream to Solr
"just works". These two curl commands did the trick, giving me a stream to work
with:
curl -X POST --form "fileupload=@schema.eoe"
'http://localhost:8983/solr/collection1/admin/file?op=write&file=schema.xml'
curl -X POST --form "fileupload=@eoe.vm"
'http://localhost:8983/solr/collection1/admin/file?op=write&file=velocity/error.vm'
[~steffkes] Is this enough to see if this could work from the admin UI?
Everyone: Mostly I'm putting this up to see what people think. [~sarowe] and I
chatted this evening, there are still some questions about how this and managed
schemas should interact when both are active at once.
You can also hide files if you so choose, the code already does that. If the UI
gives you a set of files to choose from you just wouldn't see one to try to
change although you could still cURL stuff if you wanted, but this is the admin
UI after all.
If you opened a binary file, I assume you'd see garbage and wouldn't want to
proceed anyway, but that's a bit of a hole.
We should post a warning indicating that the changes won't take effect until
after a core reload. I'm reluctant to actually reload automatically on the
theory that one might want to make a series of related changes and apply them
all at once. Perhaps [~steffkes] (or someone) could put a button on whatever
page we come up with rather than making the user go to the cores page after
editing?
What would be _really cool_ is if there were an easy way to tell if at least
the xml was well-formed before saving, but that's a bell and whistle.
One thing that we may get "for free" is editing these even if the core fails to
load. But I have to check that out when the admin UI is operational.
And I still have to check whether lazily-loaded cores work, but this is enough
for tonight.
And, as usual at this point, I haven't checked things over very carefully, run
precommit or test yet. Mostly I'm wondering what people think of the approach.
Let me know...
> Allow at least solrconfig.xml and schema.xml to be edited via the admin screen
> ------------------------------------------------------------------------------
>
> Key: SOLR-5287
> URL: https://issues.apache.org/jira/browse/SOLR-5287
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis, web gui
> Affects Versions: 4.5, 5.0
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Attachments: SOLR-5287.patch
>
>
> A user asking a question on the Solr list got me to thinking about editing
> the main config files from the Solr admin screen. I chatted briefly with
> [~steffkes] about the mechanics of this on the browser side, he doesn't see a
> problem on that end. His comment is there's no end point that'll write the
> file back.
> Am I missing something here or is this actually not a hard problem? I see a
> couple of issues off the bat, neither of which seem troublesome.
> 1> file permissions. I'd imagine lots of installations will get file
> permission exceptions if Solr tries to write the file out. Well, do a
> chmod/chown.
> 2> screwing up the system maliciously or not. I don't think this is an issue,
> this would be part of the admin handler after all.
> Does anyone have objections to the idea? And how does this fit into the work
> that [~sar...@syr.edu] has been doing?
> I can imagine this extending to SolrCloud with a "push this to ZK" option or
> something like that, perhaps not in V1 unless it's easy.....
> Of course any pointers gratefully received. Especially ones that start with
> "Don't waste your effort, it'll never work (or be accepted)"...
> Because what scares me is this seems like such an easy thing to do that would
> be a significant ease-of-use improvement, so there _has_ to be something I'm
> missing.
> So if we go forward with this we'll make this the umbrella JIRA, the two
> immediate sub-JIRAs that spring to mind will be the UI work and the endpoints
> for the UI work to use.
> I think there are only two end-points here
> 1> list all the files in the conf (or arbitrary from <solr_home>/collection)
> directory.
> 2> write this text to this file
> Possibly later we could add "clone the configs from coreX to coreY".
> BTW, I've assigned this to myself so I don't lose it, but if anyone wants to
> take it over it won't hurt my feelings a bit....
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
