Elasticsearch: Cleanup Elasticsearch configuration files support
Today Elasticsearch can be configured via YAML, JSON, or properties files. The support for properties files is undocumented and should be immediately removed. The support for JSON files should be deprecated and removed in 6.0.0.
- [x] remove support for .properties #19398
- [ ] deprecate support for .json in 2.4.0
- [ ] remove support for .json in 5.0.0
- [ ] deprecate support .yml in 2.4.0
- [ ] fail hard if .yml exists in 5.0.0
- [ ] remove check for existence of .yml in 6.0.0
jasontedor
All 3 comments
We also have the weird case of supporting both elasticsearch.yml and elasticsearch.yaml. The former is the original name, and the latter was added because .yaml is the official extension (according to yaml.org). While I understand that .yml has been around much longer, I think we should make our single configuration file name use .yaml. In addition to it being the official extension, I have also been bit before when writing rest tests and accidentally using .yml, because I had just been editing an elasticsearch.yml file.
In all 3 cases (.yml, json and properties), I think we can do this cleanly for the user by looking for the older file names on startup, and throwing an error. In 2.0, we already switched to failing if there was more than one file available.
rjernst
on 12 Jul 2016
While I understand that
.ymlhas been around much longer, I think we should make our single configuration file name use.yaml.
+1
jasontedor
on 12 Jul 2016
Relates #9706
jasontedor
on 14 Jul 2016
Related issues
rpalsaxena
·
3Comments
dawi
·
3Comments
abtpst
·
3Comments
martijnvg
·
3Comments
matthughes
·
3Comments
Most helpful comment
We also have the weird case of supporting both
elasticsearch.ymlandelasticsearch.yaml. The former is the original name, and the latter was added because.yamlis the official extension (according to yaml.org). While I understand that.ymlhas been around much longer, I think we should make our single configuration file name use.yaml. In addition to it being the official extension, I have also been bit before when writing rest tests and accidentally using.yml, because I had just been editing anelasticsearch.ymlfile.In all 3 cases (.yml, json and properties), I think we can do this cleanly for the user by looking for the older file names on startup, and throwing an error. In 2.0, we already switched to failing if there was more than one file available.