Adding new require_alias option to indexing requests
#58917
Conversation
|
Pinging @elastic/es-core-features (:Core/Features/Features) |
|
//CC |
| assertThat(autoCreateIndex.shouldAutoCreate(randomAlphaOfLengthBetween(1, 10), false, buildClusterState()), equalTo(true)); | ||
| } | ||
|
|
||
| public void testAutoCreationEnabledWithNoAutoCreateFlagSet() { |
There was a problem hiding this comment.
Where does the defaulting of request-level setting to index-level setting happen?
There was a problem hiding this comment.
I don't understand your question.
What is the default of the setting? Or how are the settings adjusted for this test?
There was a problem hiding this comment.
What I meant is more: where is the code that checks the value of the index-level setting should the request-level setting be false.
|
@benwtrent I think we should avoid putting booleans in names and ending up with double-negatives, so for example I think I would much prefer either |
|
Having a positive auto create flag might cause a security problem. What if the auto create settings for an index pattern prevent autocreation? Then a user provides a 'auto_create_index=true'? Is there a better way to provide only a restriction in autocreation policy through a flag? |
I'm not sure what security problem you're talking about, if we flipped it the default would be
What about flipping it so that it's not a double negative then, and a bit clearer: I think regardless, even having a parameter is overriding the |
I agree.
I think the reasoning here was that if the parameter was positive then if would give the impression that you could override a cluster-wide One way to avoid the double negative without creating this confusion might be to call the parameter Another option would be to call the parameter Since we wouldn't want both these options and it's hard to remove them once they're in I think it's worth more people reviewing which one to add, and the exact name of the argument. |
I'm in favour of naming the parameter along these lines, so that it clear that use case for this new parameter is to prevent accidental creation a concrete index, because an alias should exist with that same name. Also this should avoid users needing think about whether they need to use this parameter if they are using data streams. |
|
If it were |
Yes. Before you make that change, let's wait and see what the Kibana team say about whether it's ever valid in recent versions to have a concrete /cc @kobelb since you were on the email thread |
|
+1 for |
As far as I'm aware, Kibana doesn't use a concrete However, I do see merit in allowing |
|
It could be This fulfills @kobelb use case as well. But it does seem very rare for a concrete index to be created with specific mappings but NOT through templates. Templates already satisfy this type of scenario. Unless there is a strange race condition between the template being instantiated and the index write occurring. I am leaning towards Please let me know @droberts195 @dakrone @kobelb @martijnvg if this is good :). I will get cracking on it. |
Kibana isn't using index templates because the mappings can change between versions of Kibana and therefore between different |
Correct. I have limited experience in using Elasticsearch outside of Kibana, but the auto create index always struck me as unhelpful magic. It removes one step when you're getting started and playing with ES but can cause a lot of pain later on. Just out of curiosity, do we know of valid use cases for this feature? |
Assuming you mean index auto creation. Removing a single step and (pretty complex) concept early on is an extremely good use case to begin with. But, another use case is streaming data and auto creating new indices from index templates (see ILM). Also, it allows administrators to allow their users to create their own indices, but without access to any of the management APIs. |
I am happy with So please switch this PR over to implement |
droberts195
changed the title
no_auto_create to indexing requestsrequire_alias option to indexing requests
…/elasticsearch into feature/add-no_autocreate-flag
|
@elasticmachine update branch |
This commit adds the `require_alias` flag to requests that create new documents. This flag, when `true` prevents the request from automatically creating an index. Instead, the destination of the request MUST be an alias. When the flag is not set, or `false`, the behavior defaults to the `action.auto_create_index` settings. This is useful when an alias is required instead of a concrete index. closes elastic#55267
…#59769) * Adding new `require_alias` option to indexing requests (#58917) This commit adds the `require_alias` flag to requests that create new documents. This flag, when `true` prevents the request from automatically creating an index. Instead, the destination of the request MUST be an alias. When the flag is not set, or `false`, the behavior defaults to the `action.auto_create_index` settings. This is useful when an alias is required instead of a concrete index. closes #55267
This commit adds the
require_aliasflag to requests that create new documents.This flag, when
trueprevents the request from automatically creating an index. Instead, the destination of the request MUST be an alias.When the flag is not set, or
false, the behavior defaults to theaction.auto_create_indexsettings.This is useful when an alias is required instead of a concrete index.
closes #55267