elasticsearch
elasticsearch copied to clipboard
CCR should perform an input validation on the Prefix/Suffix for follower indices
Elasticsearch version (bin/elasticsearch --version
):
7.15.0
OS version (uname -a
if on a Unix-like system):
ESS
Description of the problem including expected versus actual behavior: Elasticsearch does not allow index names to have uppercase letters as per https://github.com/elastic/elasticsearch/issues/31262.
It results in:
POST TestIndexBoop/_doc
{
"beep":"boop"
}
{
"error" : {
"root_cause" : [
{
"type" : "invalid_index_name_exception",
"reason" : "Invalid index name [TestIndexBoop], must be lowercase",
"index_uuid" : "_na_",
"index" : "TestIndexBoop"
}
],
"type" : "invalid_index_name_exception",
"reason" : "Invalid index name [TestIndexBoop], must be lowercase",
"index_uuid" : "_na_",
"index" : "TestIndexBoop"
},
"status" : 400
}
However, when we try to create a CCR follower pattern, we can input the prefix and/or suffix with uppercase letters. This will eventually lead to a lot of issues and hence I think an input validation should be done to ensure the resulting index name will be lowercase only. (This likely also needs to be propagated up to Kibana).
Creating it via the API works like this, but should be rejected:
PUT /_ccr/auto_follow/noot
{
"remote_cluster": "CCR_test",
"leader_index_patterns": [
"*"
],
"follow_index_pattern": "BEEP{{leader_index}}Boop"
}
{
"acknowledged" : true
}
Steps to reproduce:
- Create two deployments and connect them via CCR
- Create a auto-follower pattern as per https://www.elastic.co/guide/en/elasticsearch/reference/current/ccr-getting-started-tutorial.html#ccr-getting-started-auto-follow either via Kibana or via the ES API
- Observe how
follow_index_pattern
takes in uppercase letters, which should not be allowed

Pinging @elastic/es-distributed (Team:Distributed)
We should indeed validate the index pattern, maybe by reusing current index/alias name validation rules (see MetadataIndexCreateService#validateIndexName)