[
https://issues.apache.org/jira/browse/SOLR-6733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16479920#comment-16479920
]
Shawn Heisey commented on SOLR-6733:
------------------------------------
This comment is really long, and I've made a lot of edits before posting it.
Hopefully it's all coherent!
You both make good points. The overall intent would be to make things *easier*
to configure, not harder. Mostly by having all the configuration for the
server centralized, with reasonable defaults for anything that's not mentioned.
Starting up with an entirely missing config would be a highly desired
secondary goal. Users would not be able to configure Jetty settings that are
not explicitly handled by our code. I think that's a plus for stability, but I
acknowledge that flexibility does take a hit. If embedded Jetty has a facility
for reading and processing configs similar to the jetty.xml used by the full
server, that could be an answer.
There will be plenty of opportunity for bikeshedding about the precise location
and format (json, xml, properties, etc) of the new config file(s). I have some
ideas for a starting point, discussed below.
[~janhoy], your comments do bring up a notion that I've mentioned elsewhere:
Always using ZK and eliminating the cloud mode distinction. After some thought
I decided to offer this solution instead, which i think has a lot of the same
code simplification without the additional administrative overhead for users
who don't want cloud:
In some cases the primary config file might only contain the TCP port, or it
could be missing/empty. Other typical settings for that config file would be
things that may differ from node to node, and might include heap size, network
interfaces to listen on, SSL config, and possibly a few more. For cloud mode,
ZK information (equivalents to zkRun and/or zkHost) would be required, and it
might have hostname information for use when registering in live_nodes.
Everything else (mostly handled by solr.in.sh, jetty config files, and solr.xml
currently) would be loaded (if found) from a conf directory or a secondary
config file that could exist in the filesystem or in ZK. Leaning more towards
a secondary config file, but if all properly named files in conf (or maybe
conf.d) were loaded, it could be a way for a user to split their config up into
logical pieces. I'm torn on whether to support per-node secondary configs in
ZK, but leaning away from it.
The startup could also look for an optional properties file and load that. For
backwards compatibility, environment variables could be checked and used when
an explicit configuration doesn't exist.
For flexibility in what a user can do, I think that all possible settings
should be honored whether they are in the primary config or the secondary, with
the exception of things that only make sense in the primary config file, such
as ZK settings and java options like heap size. If somebody puts the same
setting in different files (and it's not a setting where multiple mentions make
sense), I think the one encountered first should take precedence, and a warning
should be logged for any further occurrences.
Cores and their configs would be handled much as they are now, with
improvements handled in other issues.
For SolrCloud, SSL config could be loaded from ZK instead of a config file.
Mostly I imagine that being useful for users who create one certificate good
for all nodes, but an idea that I'm leaning away from is per-node SSL configs
in ZK.
For service installations, we can create /etc/solr/servicename, where the
primary config for the service would live. If the secondary config is not in
ZK, it would also live there.
> Umbrella issue - Solr as a standalone application
> -------------------------------------------------
>
> Key: SOLR-6733
> URL: https://issues.apache.org/jira/browse/SOLR-6733
> Project: Solr
> Issue Type: New Feature
> Reporter: Shawn Heisey
> Priority: Major
>
> Umbrella issue.
> Solr should be a standalone application, where the main method is provided by
> Solr source code.
> Here are the major tasks I envision, if we choose to embed Jetty:
> * Create org.apache.solr.start.Main (and possibly other classes in the same
> package), to be placed in solr-start.jar. The Main class will contain the
> main method that starts the embedded Jetty and Solr. I do not know how to
> adjust the build system to do this successfully.
> * Handle central configurations in code -- TCP port, SSL, and things like
> web.xml.
> * For each of these steps, clean up any test fallout.
> * Handle cloud-related configurations in code -- port, hostname, protocol,
> etc. Use the same information as the central configurations.
> * Consider whether things like authentication need changes.
> * Handle any remaining container configurations.
> I am currently imagining this work happening in a new branch and ultimately
> being applied only to master, not the stable branch.
--
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
