Today, we hit a really strange issue with Elasticsearch Curator 5.5.4 delete_indices.
Here is our action rule:
6: action: delete_indices options: ignore_empty_list: True timeout_override: continue_if_exception: False filters: - filtertype: age source: name direction: older timestring: '%Y_%m' unit: months unit_count: 3
So I had an index named like this:
or even like this:
BTW, 54b2372cdd4d073b77ed99bd5b93930f5c2c0333 is just one of our git commit sha-1.
To our surprise, the above delete_indices action actually matched and deleted both of the indices above.
On paper, there is nothing in the name of those indices suggests a match to "3 months older than 2018_10". However, it just did repeatedly, never failed.
2018-10-10 23:01:22,307 DEBUG curator.indexlist __actionable:35 Index 54b2372cdd4d073b77ed99bd5b93930f5c2c0333_204828402480248 is actionable and remains in the list.
This "54b2372cdd4d073b77ed99bd5b93930f5c2c0333" seems to be a magic number. Had I changed to a different sha-1 then it will not match, such as:
2018-10-10 23:01:22,308 DEBUG curator.indexlist filter_by_age:546 Index "8f87138194295772625d4eb6365a3f9cdc233cea_2018.10.10" does not meet provided criteria. Removing from list.
Could it be some kind of internal regex match or numeric handling/overflow problem?
Let us know if more details are needed.