node: Allow to configure tombsone lifetime #2246
Conversation
docs/storage-node-configuration.md
Outdated
| | Parameter | Type | Default value | Description | | ||
| |-----------------------------|-------|---------------|------------------------------------------------------------------------------------------------| | ||
| | `delete.tombstone_lifetime` | `int` | `5` | Tombstone lifetime for removed objects. | |
There was a problem hiding this comment.
Please clarify units for this parameter
Currently, DELETE service sets tombstone expiration epoch to `current epoch + 5`. This works less than ideal in private networks where an epoch can be e.g. 10 minutes. In this case, after a node is unavailable for more than 1 hour, already deleted objects have a chance to reappear. After this commit tombstone lifetime can be configured. Signed-off-by: Evgenii Stratonikov <e.stratonikov@yadro.com>
Codecov Report
@@ Coverage Diff @@
## support/v0.35 #2246 +/- ##
=================================================
+ Coverage 30.99% 31.00% +0.01%
=================================================
Files 383 384 +1
Lines 28419 28425 +6
=================================================
+ Hits 8808 8813 +5
- Misses 18870 18871 +1
Partials 741 741
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
|
@roman-khimov I partially agree with you. The case is that this lifetime can be arbitrary, we set it only in the DELETE service for every tombstone. Like with REGULAR objects the expiration epoch of a TOMBSTONE is not restricted. |
|
I know. Technically anyone can create this object with any desired lifetime, OK. But regular well-behaving nodes doing regular DELETEs will use some value. And it's either node-specific (but why a well-behaving node does need some specific value?) or network-specific. It's quite likely that you'll have some node using the default configuration on any network, how will this affect the network? |
|
Or take it from another perspective, you have some local configuration now that potentially affects the network globally. Is it a good thing to have? |
|
Ok, I agree, it would probably also make it easier to scale. Other thoughts? @carpawell @acid-ant @realloc This fix is kinda HOT, so I will check how invasive it is to take a network setting into account here. |
|
This parameters must be treated as a local node configuration option. While set network-wise it doesn't prevent any node from misbehavior nor affects interoperability. |
Currently, DELETE service sets tombstone expiration epoch to
current epoch + 5. This works less than ideal in private networks where an epoch can be e.g. 10 minutes. In this case, after a node is unavailable for more than 1 hour, already deleted objects have a chance to reappear.After this commit tombstone lifetime can be configured.
Signed-off-by: Evgenii Stratonikov e.stratonikov@yadro.com