Add support for a specific deprecation logging that can be used to turn
on in order to notify users of a specific feature, flag, setting,
parameter, ... being deprecated.
The deprecation logger logs with a "deprecation." prefix logge
(or "org.elasticsearch.deprecation." if full name is used), and outputs
the logging to a dedicated deprecation log file.
Deprecation logging are logged under the DEBUG category. The idea is not to
enabled them by default (under WARN or ERROR) when running embedded in
another application.
By default they are turned off (INFO), in order to turn it on, the
"deprecation" category need to be set to DEBUG. This can be set in the
logging file or using the cluster update settings API, see the documentation
Closes#11033
The main `elasticsearch.yml` file mixed configuration, documentation
and advice together.
Due to a much improved documentation at <http://www.elastic.co/guide/>,
the content has been trimmed, and only the essential settings have
been left, to prevent the urge to excessive over-configuration.
Related: 8d0f1a7d123f579fc772e82ef6b9aae08f6d13fd
Always use the LocalGateway* equivalents
We already check in the LocalGateway whether a node is a client node, or
is not master-eligible, and skip writing the state there. This allows us
to remove this code that was previously used only for tribe nodes (which
are not master eligible anyway and wouldn't write state) and in
tests (which can shake more bugs out)
PR #8464 come with a bug in the example provided.
First, the current log file is not compressed so it should not end with `.gz`.
Second, conversion pattern was removing all the log content but was printing only the log date.
Then, the current log filename was hardcoded to `elasticsearch` instead of the cluster name.
Added the http.jsonp.enable option to configure disabling of JSONP responses, as those
might pose a security risk, and can be disabled if unused.
This also fixes bugs in NettyHttpChannel
* JSONP responses were never setting application/javascript as the content-type
* The content-type and content-length headers were being overwritten even if they were set before
Closes#6164
Author: Sean Gallagher
Date: 17 Apr 2014 16:18 EDT
Removed spaces on commented lines containing config key entries to prevent
users from inadvertently messing up the indents in elasticsearch.yml.
Closes#5842
* Clean up s/ElasticSearch/Elasticsearch on docs/*
* Clean up s/ElasticSearch/Elasticsearch on src/* bin/* & pom.xml
* Clean up s/ElasticSearch/Elasticsearch on NOTICE.txt and README.textile
Closes#4634
Edited elasticsearch.yml:
* Separated different sections (using headers)
* Added more information about nodes configuration
* Added more information about various index configurations and their effects
* Added information about setting network and HTTP configuration
* Reworded information on gateway, recovery, discovery
The example configuration file should allow operations stuff to quickly
get a sense of ElasticSearch features relevant for systems support,
and to understand how to configure node, cluster, network and discovery settings.
The aim here is to vaguely respect the most often changed configuration settings,
while having some top-to-bottom conceptual integrity.
Table of Contents:
* Cluster
* Node
* Index
* Paths
* Memory
* Network And HTTP
* Gateway
* Recovery Throttling
* Discovery