[
https://issues.apache.org/jira/browse/SOLR-6734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16503760#comment-16503760
]
Shawn Heisey commented on SOLR-6734:
------------------------------------
bq. If the agent is capable of reconfiguring and restarting a node, it needs to
be secured.
That's easy enough. Only make it accessible via loopback/localhost. I had not
imagined it as something that would be accessed remotely. If there's another
viable method of interprocess communication available, we wouldn't even need a
network socket. The only caveat is that I'd very much prefer a cross-platform
implementation. If it *is* opened up beyond local access, then you're
absolutely right -- authentication would be required, and probably should NOT
have a default setting. Authentication would not be a bad plan even with
local-only access. Jetty's stop mechanism requires it and is not remotely
accessible.
bq. How would the agent start the real Solr and monitor it?
That's an excellent question. I have general thoughts, but they're mostly
untested. If process monitoring/control is too braindead in Java, which would
not surprise me at all, I have some other ideas. I will write a separate
comment to discuss the various pros and cons of those ideas.
bq. Again, I think we try to reinvent what should perhaps instead be an effort
to improve official ansible/puppet modules for Solr and ease production-grade
container-based installs.
One of the principles driving me on this issue and its parent is to make things
easier for someone to get a reasonable production installation going, using
only the Solr download and nothing else. I'm not saying that we shouldn't be
involved in designing or writing modules for deployment tools. But I don't
think we should expect the casual novice to use those tools. Also, writing
those modules will be easier if we have bulletproof installation, startup, and
configuration.
bq. Multicast is so 1990 and not supported at all in many environments, so
you'd need to build separate discovery protocols to choose from (like ES) - and
at the end of the day you'll probably end up with recommending stable
hard-wired ZK_HOSTs for production.
Another case where you might be completely right. And I would never want to
take away anyone's ability to hard-wire their ZK hosts and/or use a completely
external ensemble.
The idea that had me think of multicast is automated setup in a LAN
environment. Users install Solr on three nodes, type some *simple* commands,
and the machines find each other. Solr detects details for each server like
hostnames, IP addresses, ports (for both ZK and Solr), and possibly other
things, all automatically. The user can override what's detected if they want
to, and then one more simple command executed on any node finalizes the config
to create a fully operational cluster.
It is true that some environments will not allow multicast communication to
work. Anything involving multiple IP subnets would be unable to use it without
some significant network infrastructure configuration. But I think *most*
environments where the Solr servers are all on the same subnet would work
without issues, and I don't think the code to do it would be supremely
difficult. One of the complaints I hear about most with mutlicast-based
technologies is an abundance of traffic on the network, to the point where
network links are so overloaded that other traffic gets dropped. The traffic
levels here should be quite low, and with proper usage, will not bleed to
unexpected places in the network.
The cluster-building stuff would need a way to manually specify the information
that the automatic detection would gather, in case the automatic detection
doesn't work or the user doesn't want to use it. A mandatory key/password with
no default would have to be part of starting the automatic detection on each
node.
> Standalone solr as *two* applications -- Solr and a controlling agent
> ---------------------------------------------------------------------
>
> Key: SOLR-6734
> URL: https://issues.apache.org/jira/browse/SOLR-6734
> Project: Solr
> Issue Type: Sub-task
> Reporter: Shawn Heisey
> Priority: Major
>
> In a message to the dev list outlining reasons to switch from a webapp to a
> standalone app, Mark Miller included the idea of making Solr into two
> applications, rather than just one. There would be Solr itself, and an agent
> to control Solr.
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201305.mbox/%3C807476C6-E4C3-4E7E-9F67-2BECB63990DE%40gmail.com%3E
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
