Incorrect APE processing with object attribute condition for DeleteObject
#1572
Labels
No labels
P0
P1
P2
P3
badger
frostfs-adm
frostfs-cli
frostfs-ir
frostfs-lens
frostfs-node
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
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-node#1572
Loading…
Add table
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?
Expected Behavior
APE processing rules works the same way on any node in system
Current Behavior
APE processing rules works different depends on if node is container one or not
Possible Solution
Don't use
local
head hereheaderObjSDK, err := c.headerProvider.GetHeader(ctx, prm.Container, *prm.Object, true)
Steps to Reproduce (for bugs)
Context
We cannot use bucket policies like:
is s3-gw
Regression
Probably not. The same problem also for
v0.42.15
Your Environment
0.44.0-rc.11-52-gc6a09195
If this is going to be fixed for
object.Delete
operation, we should adopt this change in S3 gateway. Gateway now creates tombstones manually for multipart objects (TrueCloudLab/frostfs-s3-gw#559). So gateway should adopt these changes as well.@dkirillov correctly highlighted about local head-ing. It seems this is the only way is to force
CheckAPE
to fetch a full header. So, the third parameter (that's currently alwaystrue
) should be able to be set by incoming value (tofalse
)headerObjSDK, err := c.headerProvider.GetHeader(ctx, prm.Container, *prm.Object, true)
if err == nil {
header = headerObjSDK.ToV2().GetHeader()
}
The problem is that this may cause performance degradation in a scenario when a lot of delete requests are coming to non-container nodes. So, we need to compare a load results with
true
/false
The problem is not that the second parameter is true.
Setting it to
false
will merely reduce the probability of triggering this problem.The problem is that we may ignore an error and violate APE processing rules.