-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix/Unlock objects on deletion lock object #1461
Fix/Unlock objects on deletion lock object #1461
Conversation
Question[2]: do we need a separate error status for "lock object removal"? |
I tested this PR and found out that the removal of the lock object doesn't produce any error (though the lock is still not removed). Is it expected? |
@KirillovDenis, no, fixed. Also, I guess, we will add a separate status code for such cases in another PR. |
cmd/neofs-cli/modules/lock.go
Outdated
expEpoch, err := cmd.Flags().GetUint64(lockExpiresOnFlag) | ||
common.ExitOnErr(cmd, "Incorrect expiration epoch: %w", err) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could also support +X
format, which means relative to the current epoch.
The examples are here
// parseEpoch parses epoch argument. Second return value is true if |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good UX improvement
required to move that funcs to the common
pkg and reorganized client
pkg a little: d70bc5a
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ParseEpoch
is ok, but moving GetSDKClientByFlag
to common
is not worth IMO. CAn we move GetCurrentEpoch
to some other package? Or just export from modules/bearer
package, there is a number of places we do a similar thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO, internal/client/sdk.go
is smth strange: pkg exists only to hold the wrapper around SDK client and we have somehow added sdk.go
file that returns raw SDK client
but ok, moved GetCurrentEpoch
to the internal/client/sdk.go
since it is a kinda helper that works with SDK client
ParseEpoch
moved to the common
GetSDKClientByFlag
kept at its previous place
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Make `ParseEpoch` and `GetCurrentEpoch` funcs public and move the first one to the `common` package. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
`WitDeletedLockCallback` => `WithDeletedLockCallback`. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
`WitDeletedLockCallback` => `WithDeletedLockCallback`. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Document force removal behaviour in all the Storage engine parts. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Do not return `meta.ErrLockObjectRemoval` from shard's methods, add shard's own error for that. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Make `ParseEpoch` and `GetCurrentEpoch` funcs public and move the first one to the `common` package. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
`WitDeletedLockCallback` => `WithDeletedLockCallback`. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Document force removal behaviour in all the Storage engine parts. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Do not return `meta.ErrLockObjectRemoval` from shard's methods, add shard's own error for that. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Related to #1227.
Why two new options:
WithTombstoneAddress
/WithGCMark
.WithForceGCMark
to be able to delete Lock objects and unlock locked objects.WithGCMark
andWithoutLockObjectHandling
(the last is kinda optimization, we do not need to check if an object is a Lock object if we know that is it a TS/SG AND we must NOT check whether it is a Lock if we KNOW that we remove expired lock).Also, I did not want to remove TS/SG/Expired LOCKS with
WithForceGCMark
since it is not forced removal in fact.Question: does the SE need
WithForceRemoval
option or everyStorageEngine.Delete
call could be considered as a "force removal"?