Thanks for the reply. I kindda guessed that may be the reason, but still feel it's a huge loss to a well designed system. Did elastico consider any of the below?
Blocking ttl unless there was a @timestamp, or @date field? This would ensure a time series index.
Putting a default , cron like , interval, but changeable, on a ttl...tge default could even be something dumb like monthly or yearly.
I can see that a badly created index, with a ttl, especially in a cloud environment, would be a recipe for all kinds of hell breaking out, and therefore suboptimal. But as most indexes, initially, will be log based, they would typically be time series in nature, so should conform to option 2.
This way, especially in a cloud environment, where hardware could be sharing indeces from different clients, I suspect there are a multitude of well and badly written cross running over the same Es nodes, which could also unleash the Sysadmin nightmare.
I note your comment in the rollover api, which will not really help any if my use cases...as I tend to use 1 index per use case, as opposed to what I walked into with a current client where they have 28k indexes and one alias....never drooping the old ones (please don't ask...I don't know either).
The delete-by-query I hadn't realised had gone as well (3 things gone then if you include Kibana 3, which was brilliant to spin things up quickly). Luckily it looks like AWS have included that in their service, as I have been gaily doing that (and it worked), without realising it had gone ....lucky eh?
Finally, I notice that Solr has TTL, working line my suggestion 2 above. https://lucene.apache.org/solr/4_8_0/solr-core/org/apache/solr/update/processor/DocExpirationUpdateProcessorFactory.html
So, the question is open again...if apache are happy....why can't ES do likewise...but with heavy constraints obviously.
Thanks again.....I still love ES for other reasons...just every time I dip back in I seem to lose some functionality that I use