HDDS-9824. Provide CLI that scans keys for a matching container and lists keys #5724

mladjan-gadzic · 2023-12-04T13:58:28Z

What changes were proposed in this pull request?

HDDS-9824. Provide CLI that scans containers for keys

These changes are mostly quality of life improvements. There were use cases when it was necessary to check whether unhealthy container was empty. These changes help in that matter - this CLI outputs keys for input container ids (separated by comma).

How is this done? Everything was done on the client side, so there is no performance impact on the server side. RocksDB tables (keyTable, fileTable and dirTable) are read. KeyTable is pretty straightforward, it is read and container id is taken from OmKeyInfo. The situation is a little different for fileTable. In order to provide key name, fileTable and dirTable have to be read, and key name needs to be constructed, because FSO buckets does not follow the same ideology as non-FSO buckets in regards to key names.

Usage example: ozone debug ldb --db=/data/metadata/om.db ckscanner -ids=1,2,3

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-9824

How was this patch tested?

Integration tests

hadoop-ozone/tools/src/main/java/org/apache/hadoop/ozone/debug/ContainerKeyScanner.java

hadoop-ozone/tools/src/main/java/org/apache/hadoop/ozone/debug/ContainerKeyInfo.java

hadoop-ozone/tools/src/main/java/org/apache/hadoop/ozone/debug/ContainerKeyScanner.java

mladjan-gadzic · 2023-12-11T13:13:07Z

@kerneltime @hemantk-12 thanks for the review!

hadoop-ozone/tools/src/main/java/org/apache/hadoop/ozone/debug/ContainerKeyScanner.java

errose28

Thanks for adding this debug tool @mladjan-gadzic. I left some comments inline.

errose28 · 2023-12-18T21:36:50Z

hadoop-ozone/tools/src/main/java/org/apache/hadoop/ozone/admin/om/OMAdmin.java


+import static org.apache.hadoop.ozone.om.OMConfigKeys.OZONE_OM_ADDRESS_KEY;
+import static org.apache.hadoop.ozone.om.OMConfigKeys.OZONE_OM_SERVICE_IDS_KEY;
+


nit. Let's avoid import re-ordering for otherwise unaffected files.

errose28 · 2023-12-18T21:47:24Z

...ne/integration-test/src/test/java/org/apache/hadoop/ozone/debug/TestContainerKeyScanner.java

+  }
+
+  @Test
+  void testWhenThereAreKeysForConatainerIds() throws IOException {


nit.

Suggested change

void testWhenThereAreKeysForConatainerIds() throws IOException {

void testWhenThereAreKeysForContainerIds() throws IOException {

I think the same typo is in the other test name too.

errose28 · 2023-12-18T21:58:52Z

...ne/integration-test/src/test/java/org/apache/hadoop/ozone/debug/TestContainerKeyScanner.java

+  private PrintWriter pstdout, pstderr;
+  private CommandLine cmd;
+
+  private static final String KEYS_FOUND_OUTPUT = "{\n" +


Can we store the expected output in a gson or jackson object instead? IIRC gson is what's being used for client side json in other places. Then the string written to stdout can be serialized into an object of the same type and they can be compared that way. This makes sure both are valid json, is more readable, and does not require exact white space matching.

errose28 · 2023-12-18T22:01:58Z

...ne/integration-test/src/test/java/org/apache/hadoop/ozone/debug/TestContainerKeyScanner.java

+ * This class tests `ozone debug ldb ckscanner` CLI that reads from RocksDB
+ * and gets keys for container ids.
+ */
+public class TestContainerKeyScanner {


Let's add more tests for all 3 bucket layout types, buckets with multiple keys at different levels of the directory tree, keys with multiple blocks and containers, and a mix of input where some containers have keys and some do not.

I've managed to incorporate all of the above conditions into three tests.

errose28 · 2023-12-18T22:36:43Z

...ne/integration-test/src/test/java/org/apache/hadoop/ozone/debug/TestContainerKeyScanner.java

+    String volumeName = "vol1";
+    String bucketName = "bucket1";
+    // format: /volumeName/bucketName/keyName
+    String key = "/" + volumeName + "/" + bucketName + "/" + keyName;


Can we use OzoneConsts.OM_KEY_PREFIX here instead? unfortunately the usual builder for these types of things in OmMetadataManagerImpl#getOzoneKey is not static.

errose28 · 2023-12-18T23:03:18Z

hadoop-ozone/tools/src/main/java/org/apache/hadoop/ozone/debug/ContainerKeyScanner.java

+          "their keys. Example-usage: 1,11,2 (Separated by ',').")
+  private Set<Long> containerIds;
+
+  private static Map<String, OmDirectoryInfo> directoryTable;


I think the directory table may be too large to require completely loading it in to memory.

In some use cases it might be. I wasn't sure how to handle this. Reading from table multiple times is time consuming. Any chance you have an idea how this might be handled better?

errose28 · 2023-12-18T23:05:36Z

hadoop-ozone/tools/src/main/java/org/apache/hadoop/ozone/debug/ContainerKeyScanner.java

+
+    // Get all tables from RocksDB
+    List<ColumnFamilyDescriptor> columnFamilyDescriptors =
+        RocksDBUtils.getColumnFamilyDescriptors(dbPath);


Can we use OmMetadataManagerImpl as a wrapper over the RocksDB instance? I don't think OmMetadataManagerImpl should actually need an OzoneManager instance that looks like a mistake introduced in the snapshot code.

errose28 · 2023-12-18T23:25:34Z

hadoop-ozone/tools/src/main/java/org/apache/hadoop/ozone/debug/ContainerKeyScanner.java

+                        "directoryTable loaded in " + (end - start) + " ms.");
+                    isDirTableLoaded = true;
+                  }
+                  keyName.append(getFsoKeyPrefix(volumeId, bucketId, value));


Looks like this is doing a full directory walk for every key found. I think this approach would be better:

Scan the file table and save all the matching keys.

If no keys in the file table match, we are done.

Else, do one walk through the directory table to build the full paths for all of those keys.
As it is this tool is storing all matches in memory either way.

A more robust approach would be to have the tool print json matches as it goes so that it works with any size input and output. Then we would walk the directory and file table in one iteration to check for matches.

There seems to be multiple approaches on how to print output. There is something like ListVolumeHandler for listing volumes which prints out proper JSON format and then there is something like ListSubcommand for listing containers which prints out JSON-like format but not true JSON. In order to have it printed out as true JSON format, data for printing needs to be kept in memory and accessed at the time of printing out.

With above in mind would you like to see proper JSON format which is better formatted and easier for end user to read or JSON-like format which is faster performance-wise but uglier for end user?

errose28 · 2023-12-18T23:27:19Z

hadoop-ozone/tools/src/main/java/org/apache/hadoop/ozone/debug/ContainerKeyScanner.java

+      out().println("No keys were found for container IDs: " + containerIds);
+      out().println(


For json tools we should only print json to stdout and print everything else to stderr otherwise it will break when piping to tools like jq.

errose28 · 2023-12-18T23:36:01Z

hadoop-ozone/tools/src/main/java/org/apache/hadoop/ozone/debug/ContainerKeyInfoWrapper.java

+/**
+ * Class for aggregation of collected data.
+ */
+public class ContainerKeyInfoWrapper {


Can we make this an inner class of ContainerKeyScanner since it is only used in one place to wrap a method return? Also can we combine this class with ContaienrKeyInfoResponse by just doing the json processing on this object?

mladjan-gadzic · 2023-12-19T10:23:55Z

@hemantk-12 @errose28 , thank you both for the review and comments. Unfortunately, I'm currently dealing with a health crisis and won't be able to address these until the start of next week. I'll do my best to handle everything as soon as I'm able to.

mladjan-gadzic · 2024-01-12T14:00:52Z

@hemantk-12 @errose28 thank you for the review once more. I addressed all the review comments and left some inline questions. Please, let me know what do you think.

hemantk-12

Thanks @mladjan-gadzic for addressing previous review comment.

I left couple of questions and some cosmetic suggestions.

Also can you please add sample request and its output in the details? If there is any, you used for manual testing.

hadoop-ozone/tools/src/main/java/org/apache/hadoop/ozone/debug/ContainerKeyInfoResponse.java

hadoop-ozone/tools/src/main/java/org/apache/hadoop/ozone/debug/ContainerKeyScanner.java

hemantk-12 · 2024-01-23T21:12:30Z

hadoop-ozone/tools/src/main/java/org/apache/hadoop/ozone/debug/ContainerKeyScanner.java

+    }
+  }
+
+  private void processFileData(


nit: few suggestions

We recently increased chars per line to 120. Please update your IDE setting if you have not.

Use early return to avoid nesting.

I think getDirectoryTableData can be loaded outside the loops and no need to use isDirTableLoaded to check if it is loaded or not. If it is to load only when needed, may be use some other way to load lazily.

Suggested change

private void processFileData(

private void processFileData(Map<Long, List<ContainerKeyInfo>> containerKeyInfos, String key, OmKeyInfo keyInfo) {

Pair<Long, Long> volumeAndBucketId = parseKey(key);

Long volumeId = volumeAndBucketId.getLeft();

Long bucketId = volumeAndBucketId.getRight();

for (OmKeyLocationInfoGroup locationInfoGroup : keyInfo.getKeyLocationVersions()) {

for (List<OmKeyLocationInfo> locationInfos : locationInfoGroup.getLocationVersionMap().values()) {

for (OmKeyLocationInfo locationInfo : locationInfos) {

if (!containerIds.contains(locationInfo.getContainerID())) {

continue;

}

String keyName = getFsoKeyPrefix(volumeId, bucketId, keyInfo) + keyInfo.getKeyName();

List<ContainerKeyInfo> containerKeyInfoList = new ArrayList<>();

containerKeyInfoList.add(new ContainerKeyInfo(locationInfo.getContainerID(),

keyInfo.getVolumeName(), volumeId,

keyInfo.getBucketName(), bucketId, keyName,

keyInfo.getParentObjectID()));

containerKeyInfos.merge(locationInfo.getContainerID(), containerKeyInfoList,

(existingList, newList) -> {

existingList.addAll(newList);

return existingList;

});

}

}

}

}

We recently increased chars per line to 120. Please update your IDE setting if you have not.

Thanks for this! Somehow I've missed this update.

Use early return to avoid nesting.

Fixed.

I think getDirectoryTableData can be loaded outside the loops and no need to use isDirTableLoaded to check if it is loaded or not.

You are right, however, I used that to enable quick lazy loading mechanism.

If it is to load only when needed, may be use some other way to load lazily.

Do you have any suggestions for this?

My suggestion would be something similar to Lazy_initialization.

hadoop-ozone/tools/src/main/java/org/apache/hadoop/ozone/debug/ContainerKeyScanner.java

hemantk-12 · 2024-01-23T23:58:27Z

hadoop-ozone/tools/src/main/java/org/apache/hadoop/ozone/debug/ContainerKeyScanner.java

+    return Pair.of(Long.parseLong(keyParts[1]), Long.parseLong(keyParts[2]));
+  }
+
+  private void processKeyData(


Suggested change

private void processKeyData(

private void processKeyData(Map<Long, List<ContainerKeyInfo>> containerKeyInfos, OmKeyInfo keyInfo) {

long volumeId = 0L;

long bucketId = 0L;

for (OmKeyLocationInfoGroup locationInfoGroup : keyInfo.getKeyLocationVersions()) {

for (List<OmKeyLocationInfo> locationInfos : locationInfoGroup.getLocationVersionMap().values()) {

for (OmKeyLocationInfo locationInfo : locationInfos) {

if (!containerIds.contains(locationInfo.getContainerID())) {

continue;

}

List<ContainerKeyInfo> containerKeyInfoList = new ArrayList<>();

containerKeyInfoList.add(new ContainerKeyInfo(locationInfo.getContainerID(),

keyInfo.getVolumeName(), volumeId,

keyInfo.getBucketName(), bucketId, keyInfo.getKeyName(),

keyInfo.getParentObjectID()));

containerKeyInfos.merge(locationInfo.getContainerID(), containerKeyInfoList,

(existingList, newList) -> {

existingList.addAll(newList);

return existingList;

});

}

}

}

}

qq: Should we use actual volume and bucket Ids here?

If I am not mistaken, non FSO layouts does not have volume/bucket id (it is 0), so I'd keep it here as well.

ObjectId (volumeId and bucketId) still should be there no matter their type OBS or FSO.

hadoop-ozone/tools/src/main/java/org/apache/hadoop/ozone/debug/ContainerKeyScanner.java

adoroszlai

Thanks @mladjan-gadzic for working on this. I think this tool will be very useful.

adoroszlai · 2024-01-27T14:26:04Z

...ne/integration-test/src/test/java/org/apache/hadoop/ozone/debug/TestContainerKeyScanner.java

+    closeDbStore();
+
+    int exitCode = cmd.execute(cmdArgs);
+    Assertions.assertEquals(0, exitCode);


nit: please import static assertion methods.

Done. Furthermore, I am going to use assertj instead of junit assertions, because I do not like to mix those in a single test class.

adoroszlai · 2024-01-27T14:27:01Z

...ne/integration-test/src/test/java/org/apache/hadoop/ozone/debug/TestContainerKeyScanner.java

+        GSON.fromJson(stdout.toString(), ContainerKeyInfoResponse.class),
+        KEYS_FOUND_OUTPUT);
+
+    Assertions.assertTrue(stderr.toString().isEmpty());


nit: please use assertThat for better failure message

Suggested change

Assertions.assertTrue(stderr.toString().isEmpty());

assertThat(stderr.toString()).isEmpty();

(needs import static org.assertj.core.api.Assertions.assertThat)

adoroszlai · 2024-01-27T14:28:04Z

...ne/integration-test/src/test/java/org/apache/hadoop/ozone/debug/TestContainerKeyScanner.java

+    int exitCode = cmd.execute(cmdArgs);
+    Assertions.assertEquals(0, exitCode);
+
+    Assertions.assertTrue(stderr.toString().contains(KEYS_NOT_FOUND_OUTPUT));


similarly:

Suggested change

Assertions.assertTrue(stderr.toString().contains(KEYS_NOT_FOUND_OUTPUT));

assertThat(stderr.toString()).contains(KEYS_NOT_FOUND_OUTPUT);

adoroszlai · 2024-01-27T14:33:48Z

hadoop-ozone/tools/pom.xml

+    <dependency>
+      <groupId>org.mockito</groupId>
+      <artifactId>mockito-core</artifactId>
+      <scope>test</scope>
+    </dependency>
+    <dependency>
+      <groupId>org.junit.jupiter</groupId>
+      <artifactId>junit-jupiter-params</artifactId>
+      <scope>test</scope>
+    </dependency>
+    <dependency>
+      <groupId>org.mockito</groupId>
+      <artifactId>mockito-junit-jupiter</artifactId>
+      <scope>test</scope>
+    </dependency>


These dependencies are available via hdds-hadoop-dependency-test.

Suggested change

<dependency>

<groupId>org.mockito</groupId>

<artifactId>mockito-core</artifactId>

<scope>test</scope>

</dependency>

<dependency>

<groupId>org.junit.jupiter</groupId>

<artifactId>junit-jupiter-params</artifactId>

<scope>test</scope>

</dependency>

<dependency>

<groupId>org.mockito</groupId>

<artifactId>mockito-junit-jupiter</artifactId>

<scope>test</scope>

</dependency>

adoroszlai · 2024-01-27T14:34:29Z

hadoop-ozone/tools/src/main/java/org/apache/hadoop/ozone/debug/ContainerKeyInfo.java

+/**
+ * Class that holds basic key data in relation to container it is in.
+ */
+public class ContainerKeyInfo {


nit:

Suggested change

public class ContainerKeyInfo {

public final class ContainerKeyInfo {

hadoop-ozone/tools/src/main/java/org/apache/hadoop/ozone/debug/ContainerKeyInfoResponse.java

adoroszlai · 2024-01-27T14:45:06Z

hadoop-ozone/tools/src/main/java/org/apache/hadoop/ozone/debug/ContainerKeyScanner.java

+ * Parser for a list of container IDs, to scan for keys.
+ */
+@CommandLine.Command(
+    name = "ckscanner",


Please add it as a sub-command of ozone debug container, then it can be named something like keys (or list-keys / find-keys, whichever you prefer).

see hadoop-ozone/tools/src/main/java/org/apache/hadoop/ozone/debug/container/ContainerCommands.java

I'd avoid using the term scan, to avoid confusion with container scanners (data validation process in datanode).

devmadhuu

@mladjan-gadzic thanks for working on the patch , but a quick question, why we want to implement this as a CLI feature ? We already have it in recon UI.

mladjan-gadzic · 2024-01-29T18:00:53Z

Thanks @mladjan-gadzic for addressing previous review comment.

I left couple of questions and some cosmetic suggestions.

Also can you please add sample request and its output in the details? If there is any, you used for manual testing.

Thank you for the second review round. I will be sure to do that!

mladjan-gadzic · 2024-01-29T18:02:04Z

Thanks @mladjan-gadzic for working on this. I think this tool will be very useful.

Thank you for the review! Currently I am working on something else so I am going to put this PR in draft state, but I will be sure get back to this ASAP.

mladjan-gadzic · 2024-01-29T18:05:51Z

@mladjan-gadzic thanks for working on the patch , but a quick question, why we want to implement this as a CLI feature ? We already have it in recon UI.

As far as I know, complains about Recon UI that we got on this is that Recon is a little behind the real state in cluster even after refresh. Furthermore, AFAIK there is no way to check for a specific containers/keys, but UI output shows everything, and it can be hard to look through.

devmadhuu · 2024-01-30T01:46:21Z

@mladjan-gadzic thanks for working on the patch , but a quick question, why we want to implement this as a CLI feature ? We already have it in recon UI.

As far as I know, complains about Recon UI that we got on this is that Recon is a little behind the real state in cluster even after refresh. Furthermore, AFAIK there is no way to check for a specific containers/keys, but UI output shows everything, and it can be hard to look through.

@mladjan-gadzic , Recon works on eventual consistency concept as it has periodic tasks to run , so there might be some delay,but you can search any container id in UI itself

mladjan-gadzic · 2024-02-09T13:19:28Z

@mladjan-gadzic thanks for working on the patch , but a quick question, why we want to implement this as a CLI feature ? We already have it in recon UI.

As far as I know, complains about Recon UI that we got on this is that Recon is a little behind the real state in cluster even after refresh. Furthermore, AFAIK there is no way to check for a specific containers/keys, but UI output shows everything, and it can be hard to look through.

@mladjan-gadzic , Recon works on eventual consistency concept as it has periodic tasks to run , so there might be some delay,but you can search any container id in UI itself

Could you please point me to that page/endpoint? As I can remember, issue was that there was pagination, and in order to get to a particular key we'd need to know on which page it is excatly if there is large number of keys.

devmadhuu · 2024-02-09T15:21:02Z

@mladjan-gadzic thanks for working on the patch , but a quick question, why we want to implement this as a CLI feature ? We already have it in recon UI.

As far as I know, complains about Recon UI that we got on this is that Recon is a little behind the real state in cluster even after refresh. Furthermore, AFAIK there is no way to check for a specific containers/keys, but UI output shows everything, and it can be hard to look through.

@mladjan-gadzic , Recon works on eventual consistency concept as it has periodic tasks to run , so there might be some delay,but you can search any container id in UI itself

Could you please point me to that page/endpoint? As I can remember, issue was that there was pagination, and in order to get to a particular key we'd need to know on which page it is excatly if there is large number of keys.

Recon UI currently search across all pages in pagination is under development. But you can still use api/v1/containers/<container_id>/keys using curl command

errose28 · 2024-02-09T20:33:46Z

I'm +1 for adding a CLI even if Recon has a similar feature. We've also seen instances where there are issues with Recon so it would be good to have a way to check OM RocksDB directly.

Co-authored-by: Ritesh H Shukla <[email protected]>

…/ContainerKeyInfo.java Co-authored-by: Hemant Kumar <[email protected]>

…g tools like jq

hemantk-12

Overall looks good to me.

Thanks for the patch @mladjan-gadzic.

hemantk-12 · 2024-02-26T21:41:31Z

...zone/integration-test/src/test/java/org/apache/hadoop/ozone/debug/TestFindContainerKeys.java

+    createFile(volumeId, bucketId, "key4", -984L, dirObjectId2, 3L);
+    createFile(volumeId, bucketId, "key5", -983L, dirObjectId2, 4L);
+
+    closeDbStore();


Why do we need to close it in individual test when we are closing it in @AfterEach?

aswinshakil · 2024-10-25T04:26:28Z

@mladjan-gadzic There are some merge conflicts, Can you rebase this PR with the latest master? We can work on getting this merged. Thank you for your contribution.

mladjan-gadzic · 2024-10-28T15:15:06Z

@mladjan-gadzic There are some merge conflicts, Can you rebase this PR with the latest master? We can work on getting this merged. Thank you for your contribution.

hi @aswinshakil! i am working on something else right now, and to be honest i've lost context on this so i'd need some time to get back to this. if time allows, i'd get back to it in the future, but i cannot promise anything.

errose28 · 2024-11-18T23:02:10Z

Closing this for now in favor of HDDS-11747 since @sumitagrawl has started working on another implementation.

kerneltime changed the title ~~HDDS-9824. Provide CLI that scans containers for keys~~ HDDS-9824. Provide CLI that scans keys for a matching container and lists keys Dec 4, 2023

kerneltime requested review from duongkame, errose28, hemantk-12 and kerneltime December 4, 2023 17:20

kerneltime reviewed Dec 4, 2023

View reviewed changes

hadoop-ozone/tools/src/main/java/org/apache/hadoop/ozone/debug/ContainerKeyScanner.java Outdated Show resolved Hide resolved

hadoop-ozone/tools/src/main/java/org/apache/hadoop/ozone/debug/ContainerKeyScanner.java Outdated Show resolved Hide resolved

hemantk-12 reviewed Dec 11, 2023

View reviewed changes

hadoop-ozone/tools/src/main/java/org/apache/hadoop/ozone/debug/ContainerKeyInfo.java Outdated Show resolved Hide resolved

hadoop-ozone/tools/src/main/java/org/apache/hadoop/ozone/debug/ContainerKeyScanner.java Outdated Show resolved Hide resolved

hemantk-12 reviewed Dec 12, 2023

View reviewed changes

errose28 reviewed Dec 18, 2023

View reviewed changes

mladjan-gadzic marked this pull request as draft January 10, 2024 15:20

mladjan-gadzic force-pushed the HDDS-9824 branch 2 times, most recently from 9e61440 to 0ab7da8 Compare January 11, 2024 15:13

mladjan-gadzic marked this pull request as ready for review January 12, 2024 13:59

hemantk-12 reviewed Jan 24, 2024

View reviewed changes

adoroszlai reviewed Jan 27, 2024

View reviewed changes

devmadhuu reviewed Jan 29, 2024

View reviewed changes

mladjan-gadzic marked this pull request as draft January 29, 2024 18:18

mladjan-gadzic force-pushed the HDDS-9824 branch from cf5ccdf to 404b7d0 Compare February 12, 2024 08:21

xBis7 and others added 2 commits February 12, 2024 09:21

Add container key scanner command

cf21fe2

Revert non-necessary changes

a89647e

mladjan-gadzic and others added 19 commits February 12, 2024 09:21

Simplify description

653533a

Co-authored-by: Ritesh H Shukla <[email protected]>

Update hadoop-ozone/tools/src/main/java/org/apache/hadoop/ozone/debug…

06af3f8

…/ContainerKeyInfo.java Co-authored-by: Hemant Kumar <[email protected]>

Add period at the end

cb54308

Remove unnecessary code

49f3965

Use StringUtils

d0598ae

Revert reordering

6a90b3b

Move processing of data to a helper function because of too much nesting

bf0e984

Fix typo

1978578

Compare objects instead of string for json

6f2d271

Uze OM_KEY_PREFIX instead of "/"

5cffd27

Print to stderr instead of stdout in order to be compliant with pipin…

af9c494

…g tools like jq

Replace usage of ContainerKeyInfoWrapper with ContainerKeyInfoResponse

ad94ff3

Fix import order

5cd90e1

Remove multi character flags with a single dash

88488e5

Split containers ids by spaces not by commas

7efab90

Use table names from OmMetadataManagerImpl

f883524

Use OmMetadataManagerImpl as wrapper for RocksDB instance

5d581c9

Make ckscanner command as subcommand to debug command

0d03772

Rename command and put under different parent

ab9b3f0

mladjan-gadzic force-pushed the HDDS-9824 branch 2 times, most recently from e64e188 to 8d301c5 Compare February 12, 2024 11:06

Address review comments

d860f71

mladjan-gadzic force-pushed the HDDS-9824 branch from e7427c4 to d860f71 Compare February 12, 2024 15:34

mladjan-gadzic marked this pull request as ready for review February 13, 2024 00:18

hemantk-12 reviewed Feb 26, 2024

View reviewed changes

mladjan-gadzic marked this pull request as draft March 13, 2024 09:30

errose28 closed this Nov 18, 2024


		import static org.apache.hadoop.ozone.om.OMConfigKeys.OZONE_OM_ADDRESS_KEY;
		import static org.apache.hadoop.ozone.om.OMConfigKeys.OZONE_OM_SERVICE_IDS_KEY;

	void testWhenThereAreKeysForConatainerIds() throws IOException {
	void testWhenThereAreKeysForContainerIds() throws IOException {

		out().println("No keys were found for container IDs: " + containerIds);
		out().println(

-  private void processFileData(
+  private void processFileData(Map<Long, List<ContainerKeyInfo>> containerKeyInfos, String key, OmKeyInfo keyInfo) {
+    Pair<Long, Long> volumeAndBucketId = parseKey(key);
+    Long volumeId = volumeAndBucketId.getLeft();
+    Long bucketId = volumeAndBucketId.getRight();
+    for (OmKeyLocationInfoGroup locationInfoGroup : keyInfo.getKeyLocationVersions()) {
+      for (List<OmKeyLocationInfo> locationInfos : locationInfoGroup.getLocationVersionMap().values()) {
+        for (OmKeyLocationInfo locationInfo : locationInfos) {
+          if (!containerIds.contains(locationInfo.getContainerID())) {
+            continue;
+          }
+          String keyName = getFsoKeyPrefix(volumeId, bucketId, keyInfo) + keyInfo.getKeyName();
+          List<ContainerKeyInfo> containerKeyInfoList = new ArrayList<>();
+          containerKeyInfoList.add(new ContainerKeyInfo(locationInfo.getContainerID(),
+              keyInfo.getVolumeName(), volumeId,
+              keyInfo.getBucketName(), bucketId, keyName,
+              keyInfo.getParentObjectID()));
+          containerKeyInfos.merge(locationInfo.getContainerID(), containerKeyInfoList,
+              (existingList, newList) -> {
+                existingList.addAll(newList);
+                return existingList;
+              });
+        }
+      }
+    }
+  }

	Assertions.assertTrue(stderr.toString().isEmpty());
	assertThat(stderr.toString()).isEmpty();

	Assertions.assertTrue(stderr.toString().contains(KEYS_NOT_FOUND_OUTPUT));
	assertThat(stderr.toString()).contains(KEYS_NOT_FOUND_OUTPUT);

	public class ContainerKeyInfo {
	public final class ContainerKeyInfo {

HDDS-9824. Provide CLI that scans keys for a matching container and lists keys #5724

HDDS-9824. Provide CLI that scans keys for a matching container and lists keys #5724

Uh oh!

Conversation

mladjan-gadzic commented Dec 4, 2023

What changes were proposed in this pull request?

What is the link to the Apache JIRA

How was this patch tested?

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mladjan-gadzic commented Dec 11, 2023

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

errose28 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mladjan-gadzic commented Dec 19, 2023

Uh oh!

mladjan-gadzic commented Jan 12, 2024

Uh oh!

hemantk-12 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hemantk-12 left a comment •

edited

Loading

hemantk-12 Feb 26, 2024 •

edited

Loading