Update ignoreDeletionMarksDelay based on deleteDelay

[clyang82]

Set configure --ignore-deletion-marks-delay to (delete-delay)/2
Here is description from document:

I can configure --ignore-deletion-marks-delay in store (Duration after which the blocks marked for deletion will be filtered out while fetching blocks. The idea of ignore-deletion-marks-delay is to ignore blocks that are marked for deletion with some delay. This ensures store can still serve blocks that are meant to be deleted but do not have a replacement yet. If delete-delay duration is provided to compactor or bucket verify component, it will upload deletion-mark.json file to mark after what duration the block should be deleted rather than deleting the block straight away. If delete-delay is non-zero for compactor or bucket verify component, ignore-deletion-marks-delay should be set to (delete-delay)/2 so that blocks marked for deletion are filtered out while fetching blocks before being deleted from bucket. Default is 24h, half of the default value for --delete-delay on compactor)

Signed-off-by: clyang82 chuyang@redhat.com

[squat]

this has some potential weird edge cases. If someone typed 1d for the deletion delay, then we would try to parse the int 1/2, which would result in 0d. This seems slightly dangerous to do in the operator code since the code runs automatically unlike when using plain jsonnet without an operator where users have the chance to review the generated manifests before applying

[clyang82]

so do you mean that we should expose ignoreDeletionMarksDelay for customer to set?

[squat]

yes, I think this would be a good way to start working around this for now. Otherwise we need to move parsing somewhere like golang

[clyang82]

@squat PTAL. Thanks.

[squat]

Let's make sure these connects always end with a period for consistency

[clyang82]

@squat PTAL