Copies numbers for object delete operation #34
Labels
No labels
P0
P1
P2
P3
good first issue
triage
Infrastructure
blocked
bug
config
discussion
documentation
duplicate
enhancement
go
help wanted
internal
invalid
kludge
observability
perfomance
question
refactoring
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-api#34
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Is your feature request related to a problem? Please describe.
The problem is described in TrueCloudLab/frostfs-node#594
In short: when storage policy cannot be satisfied (
REP 4
and one node in maintenance mode), delete operation will always fail.Describe the solution you'd like
Delete operation produces tombstone object and puts it in nodes. Client can control number of acks from nodes with
copies_number
parameter of object put request. The same way it is possible to adoptcopies_number
orack_number
in the delete request with separate field or known x-header.Describe alternatives you've considered
Return partial success status as it proposed in #33
maintenance
status #594The notion of "tombstone" already leaks outside, so I would rather use the exact same parameter name.