Skip to content

Default action.auto_create_index to false? #23745

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jasontedor opened this issue Mar 25, 2017 · 13 comments
Closed

Default action.auto_create_index to false? #23745

jasontedor opened this issue Mar 25, 2017 · 13 comments
Labels
>breaking :Data Management/Indices APIs APIs to create and manage indices and templates >enhancement Team:Data Management Meta label for data/management team

Comments

@jasontedor
Copy link
Member

jasontedor commented Mar 25, 2017

Today we default action.auto_create_index to true. There is potential for this to be a dangerous default. In production, it means that indices might not be created with the appropriate number of primary shards and replicas, and that analyzers and mappings might not be set up before any data is indexed. It means that a wide range of PUT and POST requests against the cluster create indices (I've seen vulnerability scanners accidentally create too many indices, hurting the cluster). The question put forth here is: should we change the default to false?

Note: this issue is not a proposal, this issue is being opened for discussion to solicit feedback from the community.

@jpountz
Copy link
Contributor

jpountz commented Mar 27, 2017

For the record, there is a discussion at #20640 about moving index auto creation control to templates.

@jasontedor
Copy link
Member Author

jasontedor commented Mar 28, 2017

Indeed, where there is a proposal to ship with a default template matching * that has action.auto_create_index set to true. If there is agreement here to default action.auto_create_index to false, I think that the response to #20640 would be to not ship with a default template matching * with action.auto_create_index set to true.

@clintongormley clintongormley added :Distributed Indexing/CRUD A catch all label for issues around indexing, updating and getting a doc by id. Not search. :Data Management/Indices APIs APIs to create and manage indices and templates :Core/Infra/Settings Settings infrastructure and APIs labels Mar 28, 2017
@clintongormley
Copy link
Contributor

If we were to change the default to false, the outcomes would be:

  • You have to explicitly create an index (even an empty index) before indexing a document
  • Or you have to have a template which matches the index

The downside of removing auto-create during development is small: you just run PUT test before continuing.

In production, you almost never want a completely unmapped index to spring into existence (and if you did want that, putting an empty template which matches * would resolve that).

I'm leaning towards changing the default to false.

@javanna
Copy link
Member

javanna commented Mar 28, 2017

Does this imply that we would still do the index creation automatically but only in case there is a matching template? So the index creation step will not be mandatory at all times?

@clintongormley
Copy link
Contributor

Does this imply that we would still do the index creation automatically but only in case there is a matching template? So the index creation step will not be mandatory at all times?

Correct - if there is a matching template, the index can be created automatically (although we have spoken about setting in the template which allows this behaviour to be disabled).

Regarding the above para: why would you have a template if you don't want indices to be created automatically? One possible reason: the rollover API. Any others?

@javanna
Copy link
Member

javanna commented Mar 28, 2017

why would you have a template if you don't want indices to be created automatically?

Templates and indices may be created/managed by different people? Don't we want to still apply templates to indices that are manually created (although what is in the request has the precedence)?

@clintongormley
Copy link
Contributor

fair enough

@evanvolgas
Copy link

evanvolgas commented Apr 7, 2017

How would this work with the rollover API?

Another possibility (sake of argument, no idea if this makes sense or not): What if this were handled much like the whitelisting of backup locations? You could whitelist patterns you approve of auto-creating and disapprove of everything else.

Not really sure that would buy very much though.....

@jasontedor
Copy link
Member Author

@EvanV This is already possible (specifying a pattern) and solves the rollover problem too.

@dakrone
Copy link
Member

dakrone commented Mar 20, 2018

It appears that a consensus was reached on this issue, does this need further discussion @jasontedor or can it be marked "adopt me"?

@jasontedor jasontedor added :Data Management/Indices APIs APIs to create and manage indices and templates and removed :Core/Infra/Settings Settings infrastructure and APIs :Distributed Indexing/CRUD A catch all label for issues around indexing, updating and getting a doc by id. Not search. discuss :Data Management/Indices APIs APIs to create and manage indices and templates labels Mar 20, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra

@tmenier
Copy link

tmenier commented Apr 23, 2020

Any updates on this? I understand changing the default would be breaking, but one way to avoid that and put a little more control in the hands of developers would be to allow specifying/overriding the behavior directly in calls to the Index API. In my case I control the code that builds and queries indexes but not necessarily the cluster deployments, and I can't trust that action.auto_create_index is always false. So I do an extra call to be sure, and cache the result (to avoid lots of extra calls), which works fine, but it would sure be a lot more convenient if the index call would just fail and tell me when the index doesn't exist.

@dakrone
Copy link
Member

dakrone commented May 8, 2024

This has been open for quite a while, and hasn't had a lot of interest. For now I'm going to close this as something we aren't planning on implementing. We can re-open it later if needed.

@dakrone dakrone closed this as not planned Won't fix, can't repro, duplicate, stale May 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>breaking :Data Management/Indices APIs APIs to create and manage indices and templates >enhancement Team:Data Management Meta label for data/management team
Projects
None yet
Development

No branches or pull requests

10 participants