HDDS-8214. Recon - OM DB Insights - Key Level Info #4516

devmadhuu · 2023-04-03T05:32:16Z

Few new APIs will be exposed in Recon for below information related to keys:
Key Level Info (Tab 2): A new tab will be added in Recon to consume data from newly added APIs

Number of open keys.
Number of pending delete keys.
Containers in DELETED state in SCM and present in OM, this info will be used in another API (api/v1/<containerId>/keys) as input to get list of keys mapped to such containers.

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

For point 1 and point 2 above - API request endpoint:

GET Request - "api/v1/keys/open?limit=10&prevKey=10"
First time don't send preKey param. In 2nd page call, send preKey value as "lastKey" value got in 1st response.
Response:

{
    lastKey : 11,
    replicatedTotal: 13824,
    unreplicatedTotal: 4608,
    entities: [
    {
        path: “/vol1/bucket1/key1”,
        keyState: “Open”,
        inStateSince: 1667564193026,
        size: 1024,
        replicatedSize: 3072,
        unreplicatedSize: 1024,
        replicationType: RATIS,
        replicationFactor: THREE  
    }.
   {
        path: “/vol1/bucket1/key2”,
        keyState: “Open”,
        inStateSince: 1667564193026,
        size: 512,
        replicatedSize: 1536,
        unreplicatedSize: 512,
        replicationType: RATIS,
        replicationFactor: THREE 
    }
  ]
}

GET Request for pending delete keys- "api/v1/keys/deletePending/keys?limit=10&prevKey=10"
GET Request for pending delete directories- "api/v1/keys/deletePending/dirs?limit=10&prevKey=10"
First time don't send preKey param. In 2nd page call, send preKey value as "lastKey" value got in 1st response.
Response:

{
       lastKey : 10,
      "replicatedTotal": -1530804718628866300,
      "unreplicatedTotal": -1530804718628866300,
      "deletedkeyinfo": [
        {
          "omKeyInfoList": [
            {
              "metadata": {},
              "objectID": 0,
              "updateID": 0,
              "parentObjectID": 0,
              "volumeName": "sampleVol",
              "bucketName": "bucketOne",
              "keyName": "key_one",
              "dataSize": -1530804718628866300,
              "keyLocationVersions": [],
              "creationTime": 0,
              "modificationTime": 0,
              "replicationConfig": {
                "replicationFactor": "ONE",
                "requiredNodes": 1,
                "replicationType": "STANDALONE"
              },
              "fileChecksum": null,
              "fileName": "key_one",
              "acls": [],
              "path": "0/key_one",
              "file": false,
              "latestVersionLocations": null,
              "replicatedSize": -1530804718628866300,
              "fileEncryptionInfo": null,
              "objectInfo": "OMKeyInfo{volume='sampleVol', bucket='bucketOne',
              key='key_one', dataSize='-1530804718628866186', creationTime='0',
              objectID='0', parentID='0', replication='STANDALONE/ONE',
              fileChecksum='null}",
              "updateIDset": false
            }
          ]
        }
      ],
      "status": "OK"
    }

GET Request for 3rd point (Containers in DELETED state in SCM and present in OM) - "api/v1/containers/mismatch/deleted?limit=10&prevKey=10"
Response:

[
  {
    "containerId": 2,
    "numberOfKeys": 2,
    "pipelines": []
  }
]

How was this patch tested?

This patch was tested using Junit test case and postman as well to verify response.

kerneltime · 2023-04-10T16:34:08Z

@SaketaChalamchala can you please take a look?

ArafatKhan2198 · 2023-04-14T07:25:05Z

hadoop-ozone/recon/src/main/java/org/apache/hadoop/ozone/recon/api/OMDBInsightEndpoint.java

+      Map<Long, ContainerMetadata> omContainers =
+          reconContainerMetadataManager.getContainers(-1, 0);
+      List<ContainerInfo> deletedStateSCMContainers =
+          containerManager.getContainers(HddsProtos.LifeCycleState.DELETED);


The code does not check if the containerManager are null before calling methods on them, which could result in a NullPointerException if they are null.

This is not needed to be checked for an extra null check because this is guice framework injection mechanism and used as standard in whole ozone codebase.

ArafatKhan2198 · 2023-04-14T07:25:39Z

hadoop-ozone/recon/src/main/java/org/apache/hadoop/ozone/recon/api/OMDBInsightEndpoint.java

+
+      omContainerIdsMappedToDeletedSCMContainers.forEach(containerId -> {
+        Response keysForContainer =
+            containerEndpoint.getKeysForContainer(containerId, limit,


The code does not check if the containerEndpoint are null before calling methods on them, which could result in a NullPointerException if they are null.

This is not needed to be checked for an extra null check because this is guice framework injection mechanism and used as standard in whole ozone codebase.

ArafatKhan2198 · 2023-04-14T07:30:10Z

hadoop-ozone/recon/src/main/java/org/apache/hadoop/ozone/recon/api/OMDBInsightEndpoint.java

+   *     {
+   *         path: “/vol1/bucket1/key1”,
+   *         keyState: “Open”,
+   *         inStateSince: 1667564193026,


Would it be possible for us to improve the timestamp format for inStateSince to be more redabale like :-

"inStateSince": "2023-04-14T12:00:00Z",

Backend at server side should always use timestamp in epoch format and client/UI should convert into local timezone format, so providing in epcoh is standard way.

ArafatKhan2198 · 2023-04-14T07:39:27Z

hadoop-ozone/recon/src/main/java/org/apache/hadoop/ozone/recon/api/OMDBInsightEndpoint.java

+          omMetadataManager.getOpenKeyTable(layout);
+      try (
+          TableIterator<String, ? extends Table.KeyValue<String, OmKeyInfo>>
+              keyIter = openKeyTable.iterator()) {


It would be better to close the keyIter in case an exception is thrown so as to avoid resource locking by the iterator.

this iterator is opened in try with block and any exception thrown will not be a leak which is taken care by java. Standard way to use in many other places in Ozone code base.

ArafatKhan2198 · 2023-04-14T07:40:08Z

hadoop-ozone/recon/src/main/java/org/apache/hadoop/ozone/recon/api/OMDBInsightEndpoint.java

+        omMetadataManager.getDeletedDirTable();
+    try (
+        TableIterator<String, ? extends Table.KeyValue<String, OmKeyInfo>>
+            keyIter = deletedDirTable.iterator()) {


Close the keyIter here as well

this iterator is opened in try with block and any exception thrown will not be a leak which is taken care by java. Standard way to use in many other places in Ozone code base.

ArafatKhan2198 · 2023-04-14T07:40:50Z

hadoop-ozone/recon/src/main/java/org/apache/hadoop/ozone/recon/api/OMDBInsightEndpoint.java

+    try (
+        TableIterator<String, ? extends Table.KeyValue<String,
+            RepeatedOmKeyInfo>>
+            keyIter = deletedTable.iterator()) {


Close the keyIter here as well

this iterator is opened in try with block and any exception thrown will not be a leak which is taken care by java. Standard way to use in many other places in Ozone code base.

krishnaasawa1 · 2023-04-14T10:15:17Z

hadoop-ozone/recon/src/main/java/org/apache/hadoop/ozone/recon/api/OMDBInsightEndpoint.java

+   * }
+   */
+  @GET
+  @Path("openkeyinfo")


Can we follow proper Rest naming standards. Something like
/api/v1/keys/open
/api/v1/keys/deletePending
/api/v1/containers/mismatch or whatever is appropriate

@krishnaasawa1 - Thanks for review, however I believe above api of "openkeyinfo" is accessed using same naming standards like "/api/vi/omdbinsight/openkeyinfo", because "api/v1" is already a prefix set at all APIs top from jetty server.

That I understand I am talking about Rest Naming convention. openkeyinfo or pendingfordeletionkeyinfo is not something appropriate name or path to expose in Rest API . APIs need to be Resource Name based with Actions if required.

@krishnaasawa1 - Okay, I think I understood what you meant. I'll follow the path naming convention as suggested.

@krishnaasawa1 - Pls re-review. Changes pushed for API naming convention.

krishnaasawa1 · 2023-04-14T10:16:59Z

hadoop-ozone/recon/src/main/java/org/apache/hadoop/ozone/recon/api/OMDBInsightEndpoint.java

+        openKeyInsightInfo.getNonFSOKeyInfoList();
+    boolean isLegacyBucketLayout = true;
+    boolean recordsFetchedLimitReached = false;
+    List<KeyEntityInfo> fsoKeyInfoList = openKeyInsightInfo.getFsoKeyInfoList();


The logic for both Opentable and deleteTable seems similar with Table fetch, using iterator , creating KeyEntity and adding to Response and updating overall un replication size and replication size.
Is there a way to optimise and use common code for Table iterator and updates for Open as well deleted case.
Also for OMkeyInfo is transformed to KeyEntity object for Response in case on OpenKey as well as DeletedDir , but for deletedKey repeatedOmKeyInfo is directly returned which has OMkeyInfo List .
So not sure about this logic but either in other case we could OMkeyInfo or also transform repeatedOmKeyInfo to Keyentity List

@krishnaasawa1 thanks for your review, so on you below point:

Is there a way to optimise and use common code for Table iterator and updates for Open as well deleted case.

Both Open Key and Deleted key responses are different , though they are prepared after iteration from their respective tables. In openKey API response, logic is different as we have to consider both OBS/LEGACY and FSO buckets because the tsandard interface provided by omMetadataManager accepts bucketlayout and provides the reference of "openKeyTable" or "openFileTable" respectively and their iterators return "Table<String, OmKeyInfo>" , however in case of deletedKeys API, omMetadataManager doesn't have any standard interface for two different tables ("deletedTable" and "deletedDirectoryTable" ), so we don't have to provide bucket layout as an argument and we have to fetch data from "deletedTable" for keys and need to fetch data from "deletedDirectoryTable" for directories which is done separately in two different methods due to their tables provide different iterators like "Table<String, RepeatedOmKeyInfo>" and "Table.KeyValue<String, OmKeyInfo>>", so you can see here, iterator logic cannot be same. because one provides RepeatedKeyInfo and another just single OmKeyInfo. And that is the reason we have different response for different APIs as per design doc we discussed.

Thanks for detailed response. It's okay to keep same if we can't optimize.

krishnaasawa1 · 2023-04-14T10:21:48Z

hadoop-ozone/recon/src/main/java/org/apache/hadoop/ozone/recon/api/OMDBInsightEndpoint.java

+    return pendingForDeletionKeyInfo;
+  }
+
+  private KeyInsightInfoResp getPendingForDeletionKeyInfo(


Return KeyInsightInfoResp , Same object passed as input param KeyInsightInfoResp is returned post modification. Return seems could be void.

@krishnaasawa1 thanks for review, however this returned is not void, this KeyInsightInfoResp is passed as a empty object to populate pendingForDeltionKeys to getPendingForDeletionKeyInfo method and later after populating it , it is being passed as reference to "getPendingForDeletionDirInfo" method.

What I meant as object is passed after creating new, no need to return back KeyInsightInfoResp as calling method already have reference of same object as it only has passed as input param . It's okay to keep , if required.

@krishnaasawa1 - Thanks for elaborating, I understood your point. Will make a change.

@krishnaasawa1 - Pls re-review. Changes pushed for making methods return as void.

krishnaasawa1 · 2023-04-17T09:49:50Z

hadoop-ozone/recon/src/main/java/org/apache/hadoop/ozone/recon/api/OMDBInsightEndpoint.java

+ * 5. Amount of data mapped to pending delete keys in legacy/OBS buckets and
+ * pending delete files in FSO buckets.
+ */
+@Path("/omdbinsight")


We may not need /omdbinsight in path

We may not need /omdbinsight in path

@krishnaasawa1 this is the general convention that what this whole endpoint is about and what the APIs contains regarding, we follow this convention in other endpoints also like "MetricsProxyEndpoint", "NSSummaryEndpoint", "ClusterStateEndpoint" etc.

Those belong to /metrics , /namespace and /clusterstate APIs , so here new APIs are for Containers and Keys. Based on https://ozone.apache.org/docs/current/interface/reconapi.html it looks more appropriate to keep them in Containers and Keys category respectively as information is regarding that instead of creating appending new categories omdbinsight , scminsights , insights etc in path APIs. Those APIs can map in UI accordingly to whatever insights we want to display to user. e.g namespace apis are called from insights UI page.

Those belong to /metrics , /namespace and /clusterstate APIs , so here new APIs are for Containers and Keys. Based on https://ozone.apache.org/docs/current/interface/reconapi.html it looks more appropriate to keep them in Containers and Keys category respectively as information is regarding that instead of creating appending new categories omdbinsight , scminsights , insights etc in path APIs. Those APIs can map in UI accordingly to whatever insights we want to display to user. e.g namespace apis are called from insights UI page.

This point can be debatable, I have removed the "omdbinsight" from top path of API, however based on your earlier comment, I changed the API path to "/containers/keys/mismatch" for the API which retrieves set of keys/files/dirs which are mapped to

containers in DELETED state in SCM. so now based on above comment, we should not keep the API path as "/containers/keys/mismatch", because this API doesn't retrieve containers, so I have changed the API path by adding top level as "/keys" and rename the path like "/containers/mismatch". If you have some specific path as suggestion, pls provide as suggestion , so that I can do exactly that way.

As discussed, I have moved "/containers/mismatch/keys" to ContainerEndPoint, pls have a re-look.

krishnaasawa1 · 2023-04-17T09:54:32Z

hadoop-ozone/recon/src/main/java/org/apache/hadoop/ozone/recon/api/OMDBInsightEndpoint.java

+  /** This method retrieves set of keys/files/dirs which are mapped to
+   * containers in DELETED state in SCM. */
+  @GET
+  @Path("/keys/deletedContainers")


This is case when containers is in OM and not in SCM (deleted) , then only keys will be available.
Relevant resource path seems as /containers/mismatch/keys

This is case when containers is in OM and not in SCM (deleted) , then only keys will be available. Relevant resource path seems as /containers/mismatch/keys

@krishnaasawa1 I have done the change as per the suggestion.

krishnaasawa1 · 2023-04-17T09:56:11Z

hadoop-ozone/recon/src/main/java/org/apache/hadoop/ozone/recon/api/OMDBInsightEndpoint.java

+                  map -> deletedStateSCMContainerIds.contains(map.getKey()))
+              .map(map -> map.getKey()).collect(Collectors.toList());
+
+      omContainerIdsMappedToDeletedSCMContainers.forEach(containerId -> {


further steps only applicable if omContainerIdsMappedToDeletedSCMContainers non empty.

further steps only applicable if omContainerIdsMappedToDeletedSCMContainers non empty.

@krishnaasawa1 Not sure what you meant, I believe if this list is empty, then it will not execute and iterate forEach block.

ArafatKhan2198 · 2023-04-17T18:26:24Z

hadoop-ozone/recon/src/main/java/org/apache/hadoop/ozone/recon/api/OMDBInsightEndpoint.java

+          openKeyInsightInfo.setReplicatedTotal(
+              openKeyInsightInfo.getReplicatedTotal() +
+                  keyEntityInfo.getReplicatedSize());
+          boolean added =


We are not referencing added variable anywhere? Can we remove it

@ArafatKhan2198 though we are not using, but we are using ternary operator here and without assigning to a variable, CI complains for findbugs.

ArafatKhan2198 · 2023-04-17T18:41:30Z

...op-ozone/recon/src/main/java/org/apache/hadoop/ozone/recon/api/types/KeyInsightInfoResp.java

+  @JsonInclude(JsonInclude.Include.NON_EMPTY)
+  private List<RepeatedOmKeyInfo> repeatedOmKeyInfoList;
+
+  @JsonProperty("deleteddirinfo")


Suggested change

@JsonProperty("deleteddirinfo")

@JsonProperty("deletedDirInfo")

Apply CamelCase here

ArafatKhan2198 · 2023-04-17T18:42:05Z

...op-ozone/recon/src/main/java/org/apache/hadoop/ozone/recon/api/types/KeyInsightInfoResp.java

+  private List<KeyEntityInfo> fsoKeyInfoList;
+
+  /** List of all deleted and repeatedly deleted keys.  */
+  @JsonProperty("deletedkeyinfo")


Suggested change

@JsonProperty("deletedkeyinfo")

@JsonProperty("deletedKeyInfo")

Apply CamelCase here

ArafatKhan2198 · 2023-04-17T20:04:36Z

...op-ozone/recon/src/main/java/org/apache/hadoop/ozone/recon/api/types/KeyInsightInfoResp.java

+/**
+ * HTTP Response wrapped for keys insights.
+ */
+public class KeyInsightInfoResp {


To make things consistent with naming conventions, it's probably a good idea to rename the response class. Instead of the current name, it would be better to call it either KeyInsightInfoResponse or KeyInsightResponse.

ArafatKhan2198 · 2023-04-17T20:31:10Z

hadoop-ozone/recon/src/test/java/org/apache/hadoop/ozone/recon/api/TestOmDBInsightEndPoint.java

+        reconOMMetadataManager.getOpenKeyTable(getBucketLayout())
+            .get("/sampleVol/bucketOne/key_one");
+    Assertions.assertEquals("key_one", omKeyInfo1.getKeyName());
+    Response openKeyInfoResp = omdbInsightEndpoint.getOpenKeyInfo(-1, "");


Currently, the testGetOpenKeyInfo() method is only testing a single case. It would be good to test multiple cases such as when there are multiple open keys in the open key table or when the limit and prevKeyPrefix query parameters are used.

@ArafatKhan2198 - thanks for review. I have added few more test cases.

ArafatKhan2198 · 2023-04-17T20:43:12Z

hadoop-ozone/recon/src/test/java/org/apache/hadoop/ozone/recon/api/TestOmDBInsightEndPoint.java

+    reconContainerManager
+        .updateContainerState(ContainerID.valueOf(1),
+            HddsProtos.LifeCycleEvent.CLEANUP);
+    containerIDs = containerStateManager


Is it necessary to follow the entire Container lifecycle states from FINALIZE -> CLOSE -> DELETE -> DELETING -> CLEANUP -> DELETED and can't we just mark them as deleted?

Yes we need to follow the lifecycle, else it throws Invalid state.

ArafatKhan2198 · 2023-04-17T20:54:33Z

hadoop-ozone/recon/src/test/java/org/apache/hadoop/ozone/recon/api/TestOmDBInsightEndPoint.java

+            .get("/sampleVol/bucketOne/key_one");
+    Assertions.assertEquals("key_one",
+        repeatedOmKeyInfo1.getOmKeyInfoList().get(0).getKeyName());
+    Response deletedKeyInfo = omdbInsightEndpoint.getDeletedKeyInfo(-1, "");


Currently, the testGetDeletedKeyInfo() method is only testing a single case. It would be good to test multiple cases such as when there are multiple open keys in the open key table or when the limit and prevKeyPrefix query parameters are used.

@ArafatKhan2198 - thanks for review. I have added few more test cases.

ArafatKhan2198 · 2023-04-17T20:55:48Z

hadoop-ozone/recon/src/test/java/org/apache/hadoop/ozone/recon/api/TestOmDBInsightEndPoint.java

+    assertEquals(1, deletedSCMContainers.size());
+
+    Response deletedContainerKeysInfo =
+        omdbInsightEndpoint.getDeletedContainerKeysInfo(-1, "");


Currently, the testGetDeletedContainerKeysInfo() method is only testing a single case. It would be good to test multiple cases such as when there are multiple open keys in the open key table or when the limit and prevKeyPrefix query parameters are used.

@ArafatKhan2198 - thanks for review. I have added few more test cases.

krishnaasawa1 · 2023-04-21T06:46:41Z

hadoop-ozone/recon/src/main/java/org/apache/hadoop/ozone/recon/api/OMDBInsightEndpoint.java

+  private final ReconContainerManager containerManager;
+
+  @Inject
+  public OMDBInsightEndpoint(OzoneStorageContainerManager reconSCM,


LGTM .Just minor comment in case this endpoint class you want to name something with Keys.

Class names can be used to group the set of APIs belonged to specific feature, so I feel current name make sense here. So in future if we have more APIs related to keys, we should rather adding to same class, we can create one more class with meaningful name having APIs following the naming conventions.

krishnaasawa1 · 2023-04-21T06:49:34Z

For API documentation update you can open a separate task & update accordingly post merge.

devmadhuu · 2023-04-24T05:28:18Z

For API documentation update you can open a separate task & update accordingly post merge.

Sure. Here it is created . HDDS-8481

sumitagrawl

@devmadhuu Thanks for working over this, have few comments

sumitagrawl · 2023-05-09T14:53:17Z

hadoop-ozone/recon/src/main/java/org/apache/hadoop/ozone/recon/api/ContainerEndpoint.java

+   * containers in DELETED state in SCM. */
+  @GET
+  @Path("/mismatch/keys")
+  public Response getDeletedContainerKeysInfo(


Unable to get use case where getting keys only for deleted container from SCM. I think we should return all keys which is not present in SCM (including deleted key) which may have data loss.
Additionally need see if gap between SCM and DN if DN do not have data.

Unable to get use case where getting keys only for deleted container from SCM. I think we should return all keys which is not present in SCM (including deleted key) which may have data loss. Additionally need see if gap between SCM and DN if DN do not have data.

As discussed, Please conclude on the use case.

sumitagrawl · 2023-05-09T15:02:50Z

hadoop-ozone/recon/src/main/java/org/apache/hadoop/ozone/recon/api/OMDBInsightEndpoint.java

+          if (seekKeyValue == null ||
+              (StringUtils.isNotBlank(prevKeyPrefix) &&
+                  !seekKeyValue.getKey().equals(prevKeyPrefix))) {
+            return Response.ok(openKeyInsightInfo).build();


Here iterating over Legacy and FSO, if Legacy records not found, it will come out from loop without going to FSO. Please recheck this logic.

Here iterating over Legacy and FSO, if Legacy records not found, it will come out from loop without going to FSO. Please recheck this logic.

Thanks for pointing out Sumit, This is fixed.

sumitagrawl · 2023-05-09T15:15:04Z

hadoop-ozone/recon/src/main/java/org/apache/hadoop/ozone/recon/api/OMDBInsightEndpoint.java

+        deletedKeyAndDirInsightInfo = new KeyInsightInfoResponse();
+    getPendingForDeletionKeyInfo(limit, prevKeyPrefix,
+        deletedKeyAndDirInsightInfo);
+    getPendingForDeletionDirInfo(limit, prevKeyPrefix,


Do both have separate limit or combined limit for keyInfo and DirInfo?

Do both have separate limit or combined limit for keyInfo and DirInfo?

As of now, its combined limit because limit is done by keeping UI page in mind and API gives based on both keyInfo and DirInfo

combine limit means? limit = sizeof(keyInfoList) + sizeof(dirInfoList) ? currently its applied separately

prevKeyPrefix is applied for both keyInfoList and dirInfoList, one will fail and other will success

combine limit means? limit = sizeof(keyInfoList) + sizeof(dirInfoList) ? currently its applied separately

prevKeyPrefix is applied for both keyInfoList and dirInfoList, one will fail and other will success

@sumitagrawl - As discussed, created 2 separate APIs for pendingDeleteKeys and pendingDirs. Pls review.

sumitagrawl · 2023-05-09T15:24:56Z

hadoop-ozone/recon/src/main/java/org/apache/hadoop/ozone/recon/api/OMDBInsightEndpoint.java

+        }
+        updateReplicatedAndUnReplicatedTotal(deletedKeyAndDirInsightInfo,
+            repeatedOmKeyInfo);
+        repeatedOmKeyInfoList.add(repeatedOmKeyInfo);


how UI will know about previous key? as this is not given in output

how UI will know about previous key? as this is not given in output

This is fixed, returning the last Key in response.

sumitagrawl · 2023-05-09T15:26:55Z

hadoop-ozone/recon/src/main/java/org/apache/hadoop/ozone/recon/api/OMDBInsightEndpoint.java

+      @DefaultValue(DEFAULT_FETCH_COUNT) @QueryParam(RECON_QUERY_LIMIT)
+      int limit,
+      @DefaultValue(StringUtils.EMPTY) @QueryParam(RECON_QUERY_PREVKEY)
+      String prevKeyPrefix) {


Since query to different information, key Info and dir Info, do need have separate information for query separately OR it will be in sequence after finish dir and then query key?

Since query to different information, key Info and dir Info, do need have separate information for query separately OR it will be in sequence after finish dir and then query key?

It will be in sequence.

devmadhuu · 2023-05-11T09:06:50Z

As discussed, we'll be adding the total number of keys (open and deletePending) and amount of data mapped to those keys in a different PR to limit the code size in this PR, as this info will be added with the help of async task.

Below 3 PRs being raised for handling above: HDDS-8586, HDDS-8585, HDDS-8627

sumitagrawl

@devmadhuu Overall looks good to me, with minor comment for updating output sample with new changes.

sumitagrawl · 2023-05-17T05:00:24Z

hadoop-ozone/recon/src/main/java/org/apache/hadoop/ozone/recon/api/OMDBInsightEndpoint.java

+   *       ]
+   *     }
+   *   ],
+   *   "status": "OK"


Update the output sample with changes adding lastKey

Update the output sample with changes adding lastKey

Updated the sample response. Pls review.

sumitagrawl

@devmadhuu LGTM +1

HDDS-8214. Recon - OM DB Insights - Container Level Info.

bb3704c

adoroszlai added the recon label Apr 3, 2023

devmadhuu marked this pull request as ready for review April 3, 2023 05:44

devmadhuu marked this pull request as draft April 3, 2023 05:45

kerneltime requested review from dombizita and smengcl April 3, 2023 16:15

deveshsingh added 2 commits April 4, 2023 14:47

HDDS-8214. Recon - OM DB Insights - Key Level Info.

823ead5

HDDS-8214. Recon - OM DB Insights - Key Level Info.

f8e0d79

devmadhuu marked this pull request as ready for review April 4, 2023 14:53

deveshsingh added 5 commits April 4, 2023 21:08

HDDS-8214. Recon - OM DB Insights - Key Level Info.

8dacd12

HDDS-8214. Recon - OM DB Insights - Key Level Info.

168e651

HDDS-8214. Recon - OM DB Insights - Key Level Info.

cace42c

HDDS-8214. Recon - OM DB Insights - Key Level Info.

f628968

HDDS-8214. Recon - OM DB Insights - Key Level Info.

9fc1eaf

kerneltime self-requested a review April 10, 2023 16:33

ArafatKhan2198 requested changes Apr 14, 2023

View reviewed changes

krishnaasawa1 reviewed Apr 14, 2023

View reviewed changes

deveshsingh added 2 commits April 17, 2023 10:41

HDDS-8214. Recon - OM DB Insights - Key Level Info.

285ddb1

HDDS-8214. Recon - OM DB Insights - Key Level Info.

05141a3

krishnaasawa1 reviewed Apr 17, 2023

View reviewed changes

ArafatKhan2198 requested changes Apr 17, 2023

View reviewed changes

deveshsingh added 7 commits April 19, 2023 10:09

HDDS-8214. Recon - OM DB Insights - Key Level Info.

7091198

HDDS-8214. Recon - OM DB Insights - Key Level Info.

fb210c3

HDDS-8214. Recon - OM DB Insights - Key Level Info.

eb23a87

HDDS-8214. Recon - OM DB Insights - Key Level Info.

3e1e87b

HDDS-8214. Recon - OM DB Insights - Key Level Info.

72f6c40

HDDS-8214. Recon - OM DB Insights - Key Level Info.

18abcb9

HDDS-8214. Recon - OM DB Insights - Key Level Info.

410b846

krishnaasawa1 reviewed Apr 21, 2023

View reviewed changes

ArafatKhan2198 approved these changes Apr 24, 2023

View reviewed changes

HDDS-8214. Recon - OM DB Insights - Key Level Info.

737734c

sumitagrawl reviewed May 9, 2023

View reviewed changes

deveshsingh added 5 commits May 11, 2023 14:43

HDDS-8214. Recon - OM DB Insights - Key Level Info.

25171b5

HDDS-8214. Recon - OM DB Insights - Key Level Info.

a169db1

HDDS-8214. Recon - OM DB Insights - Key Level Info.

90c5a15

HDDS-8214. Recon - OM DB Insights - Key Level Info.

6135735

HDDS-8214. Recon - OM DB Insights - Key Level Info.

5ae1ee4

sumitagrawl reviewed May 17, 2023

View reviewed changes

HDDS-8214. Recon - OM DB Insights - Key Level Info.

76dd31a

sumitagrawl approved these changes May 17, 2023

View reviewed changes

sumitagrawl merged commit 5a6865f into apache:master May 25, 2023

smitajoshi12 mentioned this pull request Jun 20, 2023

HDDS-8415. Recon UI:OM DB Insights Changes #4940

Merged

	@JsonProperty("deleteddirinfo")
	@JsonProperty("deletedDirInfo")

	@JsonProperty("deletedkeyinfo")
	@JsonProperty("deletedKeyInfo")

HDDS-8214. Recon - OM DB Insights - Key Level Info #4516

HDDS-8214. Recon - OM DB Insights - Key Level Info #4516

Conversation

devmadhuu commented Apr 3, 2023 • edited Loading

How was this patch tested?

kerneltime commented Apr 10, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

devmadhuu Apr 19, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

krishnaasawa1 commented Apr 21, 2023

devmadhuu commented Apr 24, 2023

sumitagrawl left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

devmadhuu commented May 11, 2023 • edited Loading

sumitagrawl left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

devmadhuu commented Apr 3, 2023 •

edited

Loading

devmadhuu Apr 19, 2023 •

edited

Loading

devmadhuu commented May 11, 2023 •

edited

Loading