Documentation on storage retention is contradictory

[bpfoster]

Is your feature request related to a problem? Please describe. The documentation on storage states:

With the exception of the filesystem chunk store, Loki will not delete old chunk stores. This is generally handled instead by configuring TTLs (time to live) in the chunk store of your choice (bucket lifecycles in S3/GCS, and TTLs in Cassandra). Neither will Loki currently delete old data when your local disk fills when using the filesystem chunk store – deletion is only determined by retention duration.

I read that as - if you're not using the filesystem store, Loki will not delete old data.

The documentation on retention however, states:

retention through the Compactor is supported only with the boltdb-shipper and tsdb store

So it sounds like (and a test of the behavior seems to confirm) that when using a non-filesystem store, Loki can delete old data without the need to rely on configuring TTLs on the store.

The retention documentation also makes it sound like you can configure targeted retention policies, despite the storage page stating:

We’re interested in adding targeted deletion in future Loki releases (think tenant or stream level granularity) and may include other strategies as well.

Describe the solution you'd like I believe the storage page should be updated/reworded to make it clear that Loki is capable of cleaning up old data even when using a store other than the filesystem.

Describe alternatives you've considered n/a

Additional context I am testing with S3, TSDB, and the compactor.

[gaelayo]

Same thing here, I would also love to have more details on how to setup the retention policy on the Object Storage side (e.g S3). For example, I see the loki_cluster_seed.json file at the root of the bucket, but a naive expiration policy would delete it after some time. Is it ok ? Or should I define a specific prefix in my retention policy ?