I'm going to write this now before I forget about it.
We're going to turn off automatic index creation. We find it hides
deployment mistakes. Everything will look like it is working but you're
Italian text is suddenly missing English stop words. Correcting the
problem basically requires blowing away and recreating the index any way.
If you can use the feature either because the defaults are fine or you can
use templates or whatever, then more power to you. It really is super
convenient. I think, at least for us, turning it off makes more sense.
Maybe you too should think about it.
Index autocreation is definitely one of the features you want to turn off
in production. It's super convenient, but can lead to all sorts of problems
if you're not careful. We also disable a few other potentially dangerous
actions in production. This is snippet from our configuration:
Require explicit index creation
action.auto_create_index: false
Protect against accidental close/delete operations
on all indices. You can still close/delete individual
On Thursday, October 24, 2013 6:48:01 PM UTC-7, Dan Everton wrote:
Index autocreation is definitely one of the features you want to turn off
in production. It's super convenient, but can lead to all sorts of problems
if you're not careful.
Hear, hear.
We've been running these stricter configurations in production for Bonsai.io for ages for exactly those reasons. The difference is a periodic
source of confusion for some of our customers, and probably our largest
single source of Elasticsearch-related support questions at bonsai.io.
Index autocreation is definitely one of the features you want to turn off
in production.
This all depends who "you" are. For instance, for logging users, index
auto-creation is exactly what you want. So the "correct" setting depends
entirely on how you use Elasticsearch.
A strong theme in Elasticsearch is "just get out of the way and make it
easy to get going" and I think auto index-creation fits nicely with that
approach. Should you later want to turn it off, then fine, it's easy to do.
Something similar going for the _all field or dynamic mapping etc. They
all make it easy to get started, but can be configured to be stricter
should you desire it.
Possibly what we need instead is a page in the docs explaining these
settings so that users don't need to discover them only after being bitten
On Thursday, October 24, 2013 6:48:01 PM UTC-7, Dan Everton wrote:
Index autocreation is definitely one of the features you want to turn off
in production. It's super convenient, but can lead to all sorts of problems
if you're not careful.
Hear, hear.
We've been running these stricter configurations in production for Bonsai.io for ages for exactly those reasons. The difference is a periodic
source of confusion for some of our customers, and probably our largest
single source of Elasticsearch-related support questions at bonsai.io.
Index autocreation is definitely one of the features you want to turn
off in production.
This all depends who "you" are. For instance, for logging users, index
auto-creation is exactly what you want. So the "correct" setting depends
entirely on how you use Elasticsearch.
A strong theme in Elasticsearch is "just get out of the way and make it
easy to get going" and I think auto index-creation fits nicely with that
approach. Should you later want to turn it off, then fine, it's easy to do.
I like this argument even though I'm the one that originally complained
about it. I can see wanting to use it.
Something similar going for the _all field or dynamic mapping etc. They
all make it easy to get started, but can be configured to be stricter
should you desire it.
Maybe ironically my use case calls for turning all those off as well.
Possibly what we need instead is a page in the docs explaining these
settings so that users don't need to discover them only after being bitten
+1. A page with links to all the gotcha settings and a discussion on why
you might want to change the defaults would be perfect. As of now there
are blogs to read but none of them are really comprehensive because they
typically about that user's user case.
I think it is nice to keep in mind that it is normal for a service's
defaults not to be correct for production/high load use. Elasticsearch
kind of spoils us because the defaults actually are right in so many cases.
I like the principle "convenience over configuration".
Auto index creation may hurt in a few cases, but it is easy to turn it off.
In my production setup, auto doc ID creation sucks. So I can turn it off if
I want to. But I'd never blame ES for having auto doc ID creation turned on
by default.
An overview of Elasticsearch's convenience philosophy and why it is better
instead of hiding features would help though.
Maybe an option is to say somewhere (docs? blog? comments in config file?
all of the above?) that ES is developer-friendly and some settings should
be checked before going to production.
If you need any help, I'd be glad to contribute.
Speaking of contribuitions, here's a crazy idea: how about a GitHub repo?
It would be easier for the community to add their experience and even have
branches for use-cases like logging.
On Dec 2, 2013 6:51 PM, "joergprante@gmail.com" joergprante@gmail.com
wrote:
+1 for Clint
I like the principle "convenience over configuration".
Auto index creation may hurt in a few cases, but it is easy to turn it off.
In my production setup, auto doc ID creation sucks. So I can turn it off
if I want to. But I'd never blame ES for having auto doc ID creation turned
on by default.
An overview of Elasticsearch's convenience philosophy and why it is better
instead of hiding features would help though.
Doesn't look like this exists in the official docs yet, but this blog has a
good list of settings to check:
On Monday, December 2, 2013 1:34:33 PM UTC-6, Radu Gheorghe wrote:
+1 from me, too
Maybe an option is to say somewhere (docs? blog? comments in config file?
all of the above?) that ES is developer-friendly and some settings should
be checked before going to production.
If you need any help, I'd be glad to contribute.
Speaking of contribuitions, here's a crazy idea: how about a GitHub repo?
It would be easier for the community to add their experience and even have
branches for use-cases like logging.
On Dec 2, 2013 6:51 PM, "joerg...@gmail.com <javascript:>" < joerg...@gmail.com <javascript:>> wrote:
+1 for Clint
I like the principle "convenience over configuration".
Auto index creation may hurt in a few cases, but it is easy to turn it
off.
In my production setup, auto doc ID creation sucks. So I can turn it off
if I want to. But I'd never blame ES for having auto doc ID creation turned
on by default.
An overview of Elasticsearch's convenience philosophy and why it is
better instead of hiding features would help though.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
