Skip to content

HDDS-11705. Snapshot operations on linked buckets should work on actual underlying bucket - #7434

Merged
hemantk-12 merged 20 commits into
apache:masterfrom
swamirishi:HDDS-11705
Nov 16, 2024
Merged

HDDS-11705. Snapshot operations on linked buckets should work on actual underlying bucket#7434
hemantk-12 merged 20 commits into
apache:masterfrom
swamirishi:HDDS-11705

Conversation

@swamirishi

@swamirishiswamirishi commented Nov 14, 2024

Copy link
Copy Markdown
Contributor

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

Change-Id: I821e19b67e405d9bdffc49ad5fe8f483f224a6dd
…on actual bucket
Change-Id: I23b167deca04f5d6d8156c011300f005351892fc
@swamirishiswamirishi changed the title HDDS-11705. Snapshot diff fails on linked bucketsHDDS-11705. Snapshot operations should on linked buckets should work on actual underlying bucketNov 15, 2024
Change-Id: I2138306c1a3077ed4b77aeb1d2366c7acb8d2d66
Change-Id: I12e98b5a4f5896f1871f8b019fd6929f37e39f4a

@hemantk-12hemantk-12 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

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.

@hemantk-12hemantk-12 changed the title HDDS-11705. Snapshot operations should on linked buckets should work on actual underlying bucketHDDS-11705. Snapshot operations on linked buckets should work on actual underlying bucketNov 15, 2024
Change-Id: Ie9fec98f741c875362e904ad48b00bf9c1f286b7
@swamirishi

Copy link
Copy Markdown
ContributorAuthor

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.

That's the plan. I have made TestOmSnapshot & TestOmSnapshotFileSystemParameterized and testing a full test run on it

Change-Id: I73ca6a308e1aa4f2fa6d4de224881803b078ef25

@sumitagrawlsumitagrawl left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Few comments is given, and IMO, we should not allow snapshots over linked buckets.

Change-Id: Ib85be9bdb30ec1ea7ad055ad6cbd696ff886bcff
… perform check only external requests
Change-Id: If23f82aa5681588ac32bedb8def12d43c7bd8a5a
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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The method above this "deleteKeysFromDelKeyTableInSnapshotScope" also needs correction. Or are we planning to handle garbage collection separately?

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok you mean that the callers ensure that the method is passed the real bucket name. Makes sense in that case.

Change-Id: I65418735f650ecf4f3e6901617f8b01e5702f146
@adoroszlaiadoroszlai added the snapshot https://issues.apache.org/jira/browse/HDDS-6517 label Nov 15, 2024
Change-Id: I9cf926bfd4cf79dfd3709622108220128bbf5751
Change-Id: I4e4bfc336e70a4d5f99cb02701e494d5ea64ec4b
Change-Id: I6fd76cdbc5bce189e0d12e2295e4119f9082a317
Change-Id: I43d6a8b49ecdb4981774fa0bb53b50159f730668
Change-Id: I290d4a4ca4eb386fe9d4ccf7a8e0111d5b4017b6
Change-Id: I580ee29560a4e7b22ea80a8654dab1e392f03935
@prashantpogde

Copy link
Copy Markdown
Contributor

@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,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

@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.

As such no problem in implementation, may be caution to be added to avoid creation of multiple snapshots unknowingly, for optimization in snapshot creation.

@swamirishi
swamirishi marked this pull request as draft November 15, 2024 19:17
Change-Id: Ibaf927b11d9f617ac738921f675a0e6d3631b71f
.setVersioning(false)
.setSourceVolume(vol)
.setSourceBucket(sourceBucketName);
return createBucket(client, vol, bb.build(), linkedBucketName);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we need to call createBucket with true flag? Currently, it is calling createBucket which defaults to not linked bucket.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

createLinkedBucket is called by createBucket when the flag is true.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When the sourceBucket is present it creates a linked bucket

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);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: you can call resolveBucketLink which is default to false.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

// 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());

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yup we can create a followup jira

Change-Id: Ia080b9985766f9d6f9c4f45250db2d976334d943
Change-Id: I5262aeaf17498582fc6c46d041a8a27f99dc73b8
@swamirishi
swamirishi marked this pull request as ready for review November 15, 2024 23:38
@swamirishi

Copy link
Copy Markdown
ContributorAuthor

@hemantk-12 if you are good with the change we can merge this.

@hemantk-12hemantk-12 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM+1

@hemantk-12
hemantk-12 merged commit f60ad61 into apache:masterNov 16, 2024
@hemantk-12

Copy link
Copy Markdown
Contributor

Thanks @swamirishi for the patch, @prashantpogde@sumitagrawl@sadanand48, and @adoroszlai for the review.

Comment on lines +2974 to +2975
// 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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

snapshothttps://issues.apache.org/jira/browse/HDDS-6517

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants

@swamirishi@prashantpogde@sumitagrawl@hemantk-12@adoroszlai@sadanand48@smengcl