Uh oh!
There was an error while loading. Please reload this page.
HDDS-11705. Snapshot operations on linked buckets should work on actual underlying bucket - #7434
Conversation
Change-Id: I821e19b67e405d9bdffc49ad5fe8f483f224a6dd
…on actual bucket Change-Id: I23b167deca04f5d6d8156c011300f005351892fc
Change-Id: I2138306c1a3077ed4b77aeb1d2366c7acb8d2d66
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Change-Id: I12e98b5a4f5896f1871f8b019fd6929f37e39f4a
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Thanks @swamirishi for the quick patch.
Changes look good to me, Let's add tests around this. Specially for SnapshotDiff and listing key on Snapshot on a linked bucket.
prashantpogde
commented
Nov 15, 2024
Overall changes look good to me. Let run a full range of snapshot operations on a linked bucket to be sure that we didn't miss anything. |
Change-Id: Ie9fec98f741c875362e904ad48b00bf9c1f286b7
swamirishi
commented
Nov 15, 2024
That's the plan. I have made TestOmSnapshot & TestOmSnapshotFileSystemParameterized and testing a full test run on it |
Change-Id: I73ca6a308e1aa4f2fa6d4de224881803b078ef25
sumitagrawl
left a comment
There was a problem hiding this comment.
Few comments is given, and IMO, we should not allow snapshots over linked buckets.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Change-Id: Ib85be9bdb30ec1ea7ad055ad6cbd696ff886bcff
… perform check only external requests Change-Id: If23f82aa5681588ac32bedb8def12d43c7bd8a5a
Uh oh!
There was an error while loading. Please reload this page.
| if (isSnapshotKey(keyParts)) { | ||
| String snapshotName = keyParts[1]; | ||
| // Updating the volumeName & bucketName in case the bucket is a linked bucket. We need to do this before a |
There was a problem hiding this comment.
The method above this "deleteKeysFromDelKeyTableInSnapshotScope" also needs correction. Or are we planning to handle garbage collection separately?
There was a problem hiding this comment.
We have changed the snapshot sym link bucket name to the actual bucket name. We don't have to do anything about garbage collection code.
There was a problem hiding this comment.
Ok you mean that the callers ensure that the method is passed the real bucket name. Makes sense in that case.
Change-Id: I65418735f650ecf4f3e6901617f8b01e5702f146
Change-Id: I9cf926bfd4cf79dfd3709622108220128bbf5751
Change-Id: I4e4bfc336e70a4d5f99cb02701e494d5ea64ec4b
Change-Id: I6fd76cdbc5bce189e0d12e2295e4119f9082a317
Change-Id: I43d6a8b49ecdb4981774fa0bb53b50159f730668
Change-Id: I290d4a4ca4eb386fe9d4ccf7a8e0111d5b4017b6
Change-Id: I580ee29560a4e7b22ea80a8654dab1e392f03935
prashantpogde
commented
Nov 15, 2024
@sumitagrawl we did consider multiple links to the same destination bucket impact. It doesn't seem like it can create any problem because all the snapshot operations are still happening on the destination bucket. Let us know If you see any specific problem in allowing this. |
| // Updating the volumeName & bucketName in case the bucket is a linked bucket. We need to do this before a | ||
| // permission check, since linked bucket permissions and source bucket permissions could be different. | ||
| ResolvedBucket resolvedBucket = ozoneManager.resolveBucketLink(Pair.of(volumeName, |
There was a problem hiding this comment.
respective caller already have acl check, do this acl check additionally while getting snapshot db reference is required? It may be redundant, as used while getting metadaReader.
IMO, should be done at entry point, not in some common methods.
sumitagrawl
commented
Nov 15, 2024
As such no problem in implementation, may be caution to be added to avoid creation of multiple snapshots unknowingly, for optimization in snapshot creation. |
Change-Id: Ibaf927b11d9f617ac738921f675a0e6d3631b71f
| .setVersioning(false) | ||
| .setSourceVolume(vol) | ||
| .setSourceBucket(sourceBucketName); | ||
| return createBucket(client, vol, bb.build(), linkedBucketName); |
There was a problem hiding this comment.
Shouldn't we need to call createBucket with true flag? Currently, it is calling createBucket which defaults to not linked bucket.
There was a problem hiding this comment.
createLinkedBucket is called by createBucket when the flag is true.
There was a problem hiding this comment.
When the sourceBucket is present it creates a linked bucket
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
| try { | ||
| // Updating the volumeName & bucketName in case the bucket is a linked bucket. We need to do this before a | ||
| // permission check, since linked bucket permissions and source bucket permissions could be different. | ||
| ResolvedBucket resolvedBucket = resolveBucketLink(Pair.of(volumeName, bucketName), false); |
There was a problem hiding this comment.
nit: you can call resolveBucketLink which is default to false.
| // Updating the volumeName & bucketName in case the bucket is a linked bucket. We need to do this before a | ||
| // permission check, since linked bucket permissions and source bucket permissions could be different. | ||
| ResolvedBucket resolvedBucket = resolveBucketLink(Pair.of(volumeName, bucketName), false); | ||
| auditMap = buildAuditMap(resolvedBucket.realVolume()); |
There was a problem hiding this comment.
We don't keep audit logs for read operations. It might been copied-pasted from the write API. If agree, we can create a clean jira.
There was a problem hiding this comment.
yup we can create a followup jira
Change-Id: Ia080b9985766f9d6f9c4f45250db2d976334d943
Change-Id: I5262aeaf17498582fc6c46d041a8a27f99dc73b8
swamirishi
commented
Nov 16, 2024
@hemantk-12 if you are good with the change we can merge this. |
hemantk-12
commented
Nov 16, 2024
Thanks @swamirishi for the patch, @prashantpogde@sumitagrawl@sadanand48, and @adoroszlai for the review. |
| // Updating the volumeName & bucketName in case the bucket is a linked bucket. We need to do this before a | ||
| // permission check, since linked bucket permissions and source bucket permissions could be different. |
There was a problem hiding this comment.
I find this comment misleading.
When accessing a linked bucket, the ACL should be checked along the way. Not just on the (final) destination bucket.
That means, if:
C (linked) -> B (linked) -> A regular bucket
The user has to at least have READ permission on all of C, B and A buckets to be able to pass the ACL check.
ANY lack of permission along the chain should result in "operation denied".
At least that is how the current Ozone ACL design imposes checks on all other operations.
What changes were proposed in this pull request?
Snapshot operations on linked buckets create a snapshot on a linked bucket. However, there are potential downsides since the key prefixes in the FileTable/KeyTable/DirTable would correspond to the prefix of the actual bucket. In such a case even though a snapshot is created on the linked bucket but an SSTFilteringService run on the snapshot, the fileTable, dirTable, and keyTable would be empty since there would be no keys with the linked volume and linked bucket prefix. The same problem with other operations on the snapshot as well CreateSnapshot, DeleteSnapshot, RenameSnapshot, GetSnapshot, get key from snapshot, listing snapshots, listing snapDiff jobs, and submitting a snapshot diff job.
The solution is to resolve the bucket link to the actual bucket and perform all the snapshot operations on the actual bucket instead of the linked bucket
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-11705
How was this patch tested?
Unit tests & integration tests to follow