util: Add pretty name for resources (#918) #1201

deepakala-k · 2025-03-19T15:55:39Z

Created a helper function to fetch pretty name and added for some resources.

Chassis
FirmwareInventory
Storage
StorageController
System
Processor

Implementation Details:
The helper function makes a call to ObjectMapper to get the services that support the object path with the interfaces we want. It expects only one service is exporting the object path.

Then it will try to get the PrettyName property. If it is found and is valid, it will set the Name to the value. If not, it will use the default value that is set before the function call.

This will affect all systems and replace the Name with the PrettyName if it exist within the resource's object path.

Tested:
Passed Redfish Validator

The output names release the existing Name property only if the PrettyName property exists. If not, it will use the default value.

Output with PrettyName

$ curl  -u root:0penBmc -X GET http://${bmc}/redfish/v1/Chassis/chassis0
{
  "@odata.id": "/redfish/v1/Chassis/chassis0",
  "@odata.type": "#Chassis.v1_14_0.Chassis",
  "ChassisType": "RackMount",
  "Id": "chassis0",
  "Links": {
    "ComputerSystems": [
      {
        "@odata.id": "/redfish/v1/Systems/system"
      }
    ],
    "ManagedBy": [
      {
        "@odata.id": "/redfish/v1/Managers/bmc"
      }
    ]
  },
  "Name": "Test Chassis",
  ...
}

Without PrettyName

$ curl  -u root:0penBmc -X GET http://${bmc}/redfish/v1/Chassis/chassis0
{
  "@odata.id": "/redfish/v1/Chassis/chassis0",
  "@odata.type": "#Chassis.v1_14_0.Chassis",
  "ChassisType": "RackMount",
  "Id": "chassis0",
  "Links": {
    "ComputerSystems": [
      {
        "@odata.id": "/redfish/v1/Systems/system"
      }
    ],
    "ManagedBy": [
      {
        "@odata.id": "/redfish/v1/Managers/bmc"
      }
    ]
  },
  "Name": "chassis0",
  ...
}

Performance Diff:

Before:

$ for i in {1..5}; do
    time curl -su root:0penBmc -X GET http://${bmc}/redfish/v1/Chassis/warthog_1 > /dev/null
  done

real    0m0.314s
user    0m0.006s
sys     0m0.003s

real    0m0.346s
user    0m0.003s
sys     0m0.009s

real    0m0.369s
user    0m0.001s
sys     0m0.013s

real    0m0.343s
user    0m0.005s
sys     0m0.010s

real    0m0.356s
user    0m0.006s
sys     0m0.010s

After:

$ for i in {1..5}; do
    time curl -su root:0penBmc -X GET http://${bmc}/redfish/v1/Chassis/warthog_1 > /dev/null;
  done

real    0m0.322s
user    0m0.009s
sys     0m0.005s

real    0m0.343s
user    0m0.007s
sys     0m0.007s

real    0m0.337s
user    0m0.000s
sys     0m0.009s

real    0m0.348s
user    0m0.011s
sys     0m0.005s

real    0m0.379s
user    0m0.010s
sys     0m0.005s

Change-Id: I76e65f4aae979365266ebb38525c4ac45298737b

gtmills · 2025-03-19T16:03:53Z

Hi @deepakala-k Can you also add to Power Supply, Fan, Dimm and squash to 1 commit like you have done?
All the PrettyNames together would be helpful

d9bf7d7
5983f0e

gtmills · 2025-03-19T16:05:27Z

Also don't you need it for Fabric Adapters #869

gtmills · 2025-03-19T16:06:03Z

And assemblies #858 ?

jeaaustx · 2025-03-19T18:25:46Z

redfish-core/include/utils/name_utils.hpp

+    if (services.size() != 1)
+    {
+        BMCWEB_LOG_ERROR("Invalid Service Size  {}", services.size());
+        if (asyncResp)


In current 1110 code we are also adding all of the services to the debug log. That was added by commit 74a0b78

Can that one be included here and squashed to put all the pretty name changes together?

sure. I will pull it

redfish-core/include/utils/name_utils.hpp

jeaaustx · 2025-03-19T18:38:27Z

redfish-core/lib/chassis.hpp

-        asyncResp->res.jsonValue["Name"] = "Chassis Collection";
+        name_util::getPrettyName(asyncResp, path, connectionNames,
+                                 "/Name"_json_pointer);
+        asyncResp->res.jsonValue["ChassisType"] = "RackMount";


This should be using the enum for setting ChassisType: chassis::ChassisType::RackMount

I will remove this line from the commit? As it is not part of prettyName. I believe subsequent commits will get that code in.

Yes, please remove the line of this.
I think ChassisType is added to each chassis (not chassis collection) as in upstream, and also it is not a part of this prettyName.

DEL> asyncResp->res.jsonValue["ChassisType"] = "RackMount";

jeaaustx · 2025-03-19T18:43:25Z

redfish-core/lib/storage.hpp

-                            BMCWEB_REDFISH_SYSTEM_URI_NAME, driveId);
-    asyncResp->res.jsonValue["Name"] = driveId;
+    asyncResp->res.jsonValue["@odata.id"] = boost::urls::format(
+        "/redfish/v1/Systems/system/Storage/1/Drives/{}", driveId);


This should be using the BMCWEB_REDFISH_SYSTEM_URI_NAME setting to match upstream.

I will revert the odata.id change. Should the pretty name be used for the name property or should that also be reverted to
asyncResp->res.jsonValue["Name"] = driveId; I see that the "Id" is anyways populated with driveId

As @jeaaustx pointed out, this would be -- as in https://github.com/openbmc/bmcweb/blob/193582b6c4acc1eb60eb8ca1f445e3af4f3fe6d8/redfish-core/lib/storage.hpp#L664

asyncResp->res.jsonValue["@odata.id"] = boost::urls::format("/redfish/v1/Systems/{}/Storage/1/Drives/{}", BMCWEB_REDFISH_SYSTEM_URI_NAME, driveId);

deepakala-k · 2025-03-20T14:50:02Z

And assemblies #858 ?

I could not get that as the assembly.hpp file is not yet in 1120

deepakala-k · 2025-03-21T04:01:24Z

Also don't you need it for Fabric Adapters #869

I am unable to get this as redfish-core/lib/fabric_ports.hpp is not present in 1120.

baemyung · 2025-03-24T14:30:55Z

I could not get that as the assembly.hpp file is not yet in 1120
I am unable to get this as redfish-core/lib/fabric_ports.hpp is not present in 1120.

I think we can make this PR as WIP and wait for a while (so that the others can be rebased).

For example,

Assembly - 1120: Inventory properties via Assembly schema on bmcweb (#816)(#844)(#1134) #1205 is being reviewed
Ports - it is being worked (also for openbmc backend). So this may take some more time

gtmills · 2025-03-24T14:40:21Z

I think we can make this PR as WIP and wait for a while (so that the others can be rebased).
For example,
Assembly - #1205 is being reviewed
Ports - it is being worked (also for openbmc backend). So this may take some more time

I am okay either way. I am okay with this going first then being added to assembly and ports later

deepakala-k · 2025-03-24T14:42:17Z

I think we can make this PR as WIP and wait for a while (so that the others can be rebased).
For example,
Assembly - #1205 is being reviewed
Ports - it is being worked (also for openbmc backend). So this may take some more time

I am okay either way. I am okay with this going first then being added to assembly and ports later

I can wait, so it becomes easier to handle in the future

baemyung · 2025-03-28T13:19:28Z

I think we can make this PR as WIP and wait for a while (so that the others can be rebased).
For example,
Assembly - #1205 is being reviewed
Ports - it is being worked (also for openbmc backend). So this may take some more time

I am okay either way. I am okay with this going first then being added to assembly and ports later

I can wait, so it becomes easier to handle in the future

All dependent PRs are merged.

@deepakala-k
So, please go ahead to complete this PR.

Assembly - 1120: Inventory properties via Assembly schema on bmcweb (#816)(#844)(#1134) #1205
Port - 1120: Implement Fabric PortCollection and Port schemas (#947) #1215

deepakala-k · 2025-04-01T07:16:07Z

@baemyung In the fabric_ports.hpp
It also needs some of the changes from this commit. 6d5d94a

e.g. The pretty name PR alters afterGetAssociatedFabricPortSubTree method, which is not yet added

baemyung · 2025-04-01T10:25:18Z

@baemyung In the fabric_ports.hpp It also needs some of the changes from this commit. 6d5d94a

e.g. The pretty name PR alters afterGetAssociatedFabricPortSubTree method, which is not yet added

The current fabric_ports.hpp is not using afterGetAssociatedFabricPortSubTree but it uses getAssociatedSubTreePathsById (by getValidFabricPortPath).

BTW, is this PrettyName replacing Name?
If so, wouldn't it be to change this -

bmcweb/redfish-core/lib/fabric_ports.hpp

Line 159 in fc1dcb8

asyncResp->res.jsonValue["Name"] = "Fabric Port";

baemyung

In addition to a comment about fabric_ports.hpp & comparing with 1110, fabric_adapters.hpp seems not done for 1120.

deepakala-k · 2025-04-01T10:41:30Z

In addition to a comment about fabric_ports.hpp & comparing with 1110, fabric_adapters.hpp seems not done for 1120.

So, should i wait for all of those commits to be in?

baemyung · 2025-04-01T16:12:27Z

In addition to a comment about fabric_ports.hpp & comparing with 1110, fabric_adapters.hpp seems not done for 1120.

So, should i wait for all of those commits to be in?

The dependent codes are currently ready.
Please do this prettyName parts (e.g. fabric_ports.hpp & fabric_adapters.hpp) with the latest 1120 code.

baemyung

There is also a few piece.

pcie.hpp.
In fact, 1110 code also seems incorrect (similar processor.hpp). I think getPrettyName() should be moved into addPCIeDeviceCommonProperties

baemyung · 2025-04-04T10:03:34Z

redfish-core/lib/memory.hpp

                    dimmInterface = true;
                    found = true;
+                    name_util::getPrettyName(asyncResp, objectPath, serviceMap,
+                                             "/Name"_json_pointer);


Why should this be here?
Because getPrettyName() expects only one service, I don't think it needs to be in a loop.
Should be this moved to L412?

doing it here as compared to Ln412 is almost the same. If we called at Ln.412, we got to pass the service name as assembleDimmProperties does not have service name. That can be done. But otherwise I do not see it getting called in a loop.

afterGetDimmData -> getDimmDataByService -> assembleDimmProperties ->Ln412

I meant -- more put it inside getDimmDataByService(service) or more like inside ` assembleDimmProperties() by passing 'service', as Name is one of properties...

Addressed it. I didnt have to call getPrettyName as all the properties are anyways read and so I added pretty name to it. And tested the same. It works as expected.

baemyung · 2025-04-04T10:12:59Z

redfish-core/lib/processor.hpp


                    callback(objectPath, serviceMap);
+                    name_util::getPrettyName(asyncResp, objectPath, serviceMap,
+                                             "/Name"_json_pointer);


I also think this is not a right place.
This function handleProcessorSubtree() is an intermediate callback of getProcessorObject() (which is not a direct GET function, and it is also used by PATCH).

getPrettyName() should be done for GET - i.e. replacing "Name".
So, the right place to do is L297 - in getCpuDataByService() which is a part of getProcessorData().

I also think 1110 code also needs to be changed.

The problem everywhere is that we need to find the service name, which we get in one of these methods. I know we could do the right way. But just trying to ensure that we do not break something that is already working. Will it affect if we update the pretty name in the patch function?

Have you tried PATCH for Processor and see what's returned?

For example, this PATCH is issued, it goes thru getPrettyName() which is not needed.

Enable debug level

root@p10bmc:~# bmcweb loglevel debug <6>[webserver_cli.cpp:88] logging level changed to: DEBUG root@p10bmc:~# journalctl -f

Run PATCH
curl -k -H "Content-Type: application/json" -X PATCH https://${bmc}/redfish/v1/Systems/system/Processors/dcm0-cpu0 -d '{"LocationIndicatorActive":true}'

Then we can see

Apr 05 13:32:48 p10bmc bmcwebd[920]: [routing.hpp:652] Matched rule '/redfish/v1/Systems/<str>/Processors/<str>/' PATCH / 16 Apr 05 13:32:48 p10bmc bmcwebd[920]: [http_connection.hpp:906] 0x2708bc0 Timer canceled Apr 05 13:32:48 p10bmc bmcwebd[920]: [dbus_privileges.hpp:59] userName = service userRole = Apr 05 13:32:48 p10bmc bmcwebd[920]: [query.hpp:125] setup redfish route Apr 05 13:32:48 p10bmc bmcwebd[920]: [processor.hpp:845] Get available system processor resources. Apr 05 13:32:48 p10bmc bmcwebd[920]: [led.hpp:427] Set LocationIndicatorActive for /xyz/openbmc_project/inventory/system/chassis/motherboard/dcm0/cpu0 Apr 05 13:32:48 p10bmc bmcwebd[920]: [name_utils.hpp:73] Get PrettyName with MapperServiceMap for: /xyz/openbmc_project/inventory/system/chassis/motherboard/dcm0/cpu0 Apr 05 13:32:48 p10bmc bmcwebd[920]: [name_utils.hpp:34] Get PrettyName for: /xyz/openbmc_project/inventory/system/chassis/motherboard/dcm0/cpu0 Apr 05 13:32:48 p10bmc bmcwebd[920]: [name_utils.hpp:51] Pretty Name: System processor module 0 Apr 05 13:32:48 p10bmc bmcwebd[920]: [http_response.hpp:259] 0x26d3620 calling completion handler Apr 05 13:32:48 p10bmc bmcwebd[920]: [http_response.hpp:262] 0x26d3620 completion handler was valid Apr 05 13:32:48 p10bmc bmcwebd[920]: [http_response.hpp:97] Moving response containers; this: 0x270ae08; other: 0x26d3620 Apr 05 13:32:48 p10bmc bmcwebd[920]: [audit_events.cpp:250] auditEvent: bufLeft=152 opPathLen=57 detailLen=33 userLen=14 Apr 05 13:32:48 p10bmc bmcwebd[920]: [complete_response_fields.hpp:25] Response: 204 Apr 05 13:32:48 p10bmc bmcwebd[920]: [http_connection.hpp:851] 0x2708bc0 doWrite Apr 05 13:32:48 p10bmc bmcwebd[920]: [http_response.hpp:213] 0x270ae08 Response content provided but code was no-content or not_modified, which aren't allowed to have a body Apr 05 13:32:48 p10bmc bmcwebd[920]: [http_connection.hpp:934] 0x2708bc0 timer started Apr 05 13:32:48 p10bmc bmcwebd[920]: [http_body.hpp:198] Returning 41 bytes more=false Apr 05 13:32:48 p10bmc bmcwebd[920]: [http_response.hpp:269] 0x270ae08 setting completion handler Apr 05 13:32:48 p10bmc bmcwebd[920]: [http_connection.hpp:799] 0x2708bc0 async_write wrote 352 bytes, ec=Success [system:0]

Thanks fir checking. I will try to fix it

The fix seems good for 1120.
Would you also create a PR for 1110?

I will create a PR for 1110 processor.hpp shortly, by the eod

baemyung · 2025-04-04T14:13:05Z

This PR also handles #992

deepakala-k · 2025-04-04T14:28:22Z

There is also a few piece.

pcie.hpp.
In fact, 1110 code also seems incorrect (similar processor.hpp). I think getPrettyName() should be moved into addPCIeDeviceCommonProperties

The problem is the same. We do not have the service name and probably the best way would be move those into a function and call it both from get and patch. I guess handle was created with that intent. But we need to create another level of method may be!

baemyung · 2025-04-04T17:11:29Z

addPCIeDeviceCommonProperties

For 1110 pcie.hpp, I may misread the code. It is done for GET only.
No need to change for pcie.hpp / 1110.

baemyung · 2025-04-07T14:14:39Z

redfish-core/lib/memory.hpp

+    if (prettyName != nullptr)
+    {
+        asyncResp->res.jsonValue[jsonPtr]["Name"] = *prettyName;
+    }


Perhaps, for the consistency, would it be better to use getPrettyName() function by either passing serviceName to assembleDimmProperties(), or doing it like this?

inline void getDimmDataByService( std::shared_ptr<bmcweb::AsyncResp> asyncResp, const std::string& dimmId, const std::string& service, const std::string& objPath) { ... name_util::getPrettyName(asyncResp, objPath, service, "/Name"_json_pointer); ... dbus::utility::getAllProperties( .... }); }

I will better do it here, because in the future if people look into assembleDimmProperties and start questioning why we are again making separate call for pretty name, it might be confusing.

baemyung · 2025-04-08T12:03:05Z

redfish-core/lib/assembly.hpp

 #include <nlohmann/json.hpp>
 #include <sdbusplus/asio/property.hpp>
 #include <sdbusplus/unpack_properties.hpp>
+#include <utils/name_utils.hpp>


This would be at L16

#include "utils/name_utils.hpp"

baemyung · 2025-04-08T12:03:31Z

redfish-core/lib/fabric_adapters.hpp

 #include <boost/url/format.hpp>
 #include <sdbusplus/message/native_types.hpp>
 #include <sdbusplus/unpack_properties.hpp>
+#include <utils/name_utils.hpp>


Move to L20

#include "utils/name_utils.hpp"

baemyung · 2025-04-08T12:03:48Z

redfish-core/lib/fabric_ports.hpp

 #include <boost/system/error_code.hpp>
 #include <boost/url/format.hpp>
 #include <sdbusplus/asio/property.hpp>
+#include <utils/name_utils.hpp>


Move to L20

#include "utils/name_utils.hpp"

baemyung · 2025-04-08T12:04:08Z

redfish-core/lib/memory.hpp

    const std::string& service, const std::string& objPath)
 {
    BMCWEB_LOG_DEBUG("Get available system components.");
+    name_util::getPrettyName(asyncResp, objPath, service, "/Name"_json_pointer);


Missing

#include "utils/name_utils.hpp"

baemyung · 2025-04-08T12:25:49Z

redfish-core/lib/memory.hpp

 #include "utils/dbus_utils.hpp"
 #include "utils/hex_utils.hpp"
+#include "utils/name_utils.hpp"
 #include "utils/json_utils.hpp"


Rearrange this

#include "utils/json_utils.hpp" #include "utils/name_utils.hpp"

sorry, my docker does not work. And I have to use the CI to look for the formatting changes. Thanks a lot! I will fix my docker soon!

baemyung

One more comment. I think it is getting close.

baemyung · 2025-04-08T14:49:54Z

redfish-core/lib/storage.hpp

        boost::urls::format("/redfish/v1/Systems/{}/Storage/1/Drives/{}",
                            BMCWEB_REDFISH_SYSTEM_URI_NAME, driveId);
-    asyncResp->res.jsonValue["Name"] = driveId;
+    name_util::getPrettyName(asyncResp, path, drive->second,


L663 sets connectionNames for drive->second.
So, this may be better to be like

name_util::getPrettyName(asyncResp, path, connectionNames,

Created a helper function to fetch pretty name and added for some resources. - Chassis - FirmwareInventory - Storage - StorageController - System - Processor - Fan - Fabric Adaptor - Memory - Assembly Implementation Details: The helper function makes a call to ObjectMapper to get the services that support the object path with the interfaces we want. It expects only one service is exporting the object path. Then it will try to get the `PrettyName` property. If it is found and is valid, it will set the `Name` to the value. If not, it will use the default value that is set before the function call. This will affect all systems and replace the Name with the PrettyName if it exist within the resource's object path. Tested: Passed Redfish Validator The output names release the existing `Name` property only if the PrettyName property exists. If not, it will use the default value. Output with PrettyName ``` $ curl -u root:0penBmc -X GET http://${bmc}/redfish/v1/Chassis/chassis0 { "@odata.id": "/redfish/v1/Chassis/chassis0", "@odata.type": "#Chassis.v1_14_0.Chassis", "ChassisType": "RackMount", "Id": "chassis0", "Links": { "ComputerSystems": [ { "@odata.id": "/redfish/v1/Systems/system" } ], "ManagedBy": [ { "@odata.id": "/redfish/v1/Managers/bmc" } ] }, "Name": "Test Chassis", ... } ``` Without PrettyName ``` $ curl -u root:0penBmc -X GET http://${bmc}/redfish/v1/Chassis/chassis0 { "@odata.id": "/redfish/v1/Chassis/chassis0", "@odata.type": "#Chassis.v1_14_0.Chassis", "ChassisType": "RackMount", "Id": "chassis0", "Links": { "ComputerSystems": [ { "@odata.id": "/redfish/v1/Systems/system" } ], "ManagedBy": [ { "@odata.id": "/redfish/v1/Managers/bmc" } ] }, "Name": "chassis0", ... } ``` Squashed following commits: Logging invalid service name for debug Util api to fetch pretty name for assemblies Dimm: Look at Pretty Name (#973) (#1111) Add pretty name for fabric adapters (#869) The method getPrettyName() may be called more than one time. This will generate journal logging messages for the required Service name if there are unexpected service names. In case prettyName is blank for that FRU, then last part of the object path will be used to populate assembly name. Signed-off-by: Willy Tu <[email protected]> Co-authored-by: Willy Tu <[email protected]> Co-authored-by: Sunny Srivastava <[email protected]> Co-authored-by: Gunnar Mills <[email protected]>

deepakala-k · 2025-04-08T16:29:10Z

I will get the 1110 PR by tomorrow.

deepakala-k · 2025-04-08T16:32:28Z

Just started it. #1234
I need to work further on it

baemyung

Looks good to me

baemyung · 2025-04-11T17:59:13Z

There is also a few piece.

pcie.hpp.
In fact, 1110 code also seems incorrect (similar processor.hpp). I think getPrettyName() should be moved into addPCIeDeviceCommonProperties

The problem is the same. We do not have the service name and probably the best way would be move those into a function and call it both from get and patch. I guess handle was created with that intent. But we need to create another level of method may be!

I thought getPrettyName for pcie.hpp is handled by this PR....but it turns out it is missed.

baemyung · 2025-04-11T18:00:21Z

There is also a few piece.

pcie.hpp.
In fact, 1110 code also seems incorrect (similar processor.hpp). I think getPrettyName() should be moved into addPCIeDeviceCommonProperties

The problem is the same. We do not have the service name and probably the best way would be move those into a function and call it both from get and patch. I guess handle was created with that intent. But we need to create another level of method may be!

I thought getPrettyName for pcie.hpp is handled by this PR....but it turns out it is missed.

It looks like another PR #1201 is trying to handle for pcie.hpp.

gtmills requested review from baemyung and jeaaustx March 19, 2025 17:32

jeaaustx reviewed Mar 19, 2025

View reviewed changes

deepakala-k force-pushed the rebase_pretty_name branch 9 times, most recently from c3f0607 to b3b433c Compare March 24, 2025 12:19

deepakala-k force-pushed the rebase_pretty_name branch 2 times, most recently from d99d419 to 115e43e Compare April 1, 2025 07:36

baemyung reviewed Apr 1, 2025

View reviewed changes

deepakala-k force-pushed the rebase_pretty_name branch 2 times, most recently from 8d49bdb to 30c2213 Compare April 2, 2025 14:15

deepakala-k force-pushed the rebase_pretty_name branch 2 times, most recently from 948e4c7 to a47eb3f Compare April 4, 2025 06:07

deepakala-k requested a review from baemyung April 4, 2025 10:04

baemyung reviewed Apr 4, 2025

View reviewed changes

deepakala-k force-pushed the rebase_pretty_name branch 3 times, most recently from 27036d7 to 577d3a0 Compare April 7, 2025 13:16

deepakala-k requested a review from baemyung April 7, 2025 14:05

baemyung reviewed Apr 7, 2025

View reviewed changes

deepakala-k force-pushed the rebase_pretty_name branch 2 times, most recently from 576332d to 804f5f1 Compare April 8, 2025 07:04

baemyung reviewed Apr 8, 2025

View reviewed changes

deepakala-k force-pushed the rebase_pretty_name branch from 804f5f1 to 35df10f Compare April 8, 2025 12:15

baemyung reviewed Apr 8, 2025

View reviewed changes

deepakala-k force-pushed the rebase_pretty_name branch 2 times, most recently from 0e7f0a8 to 27c9fde Compare April 8, 2025 12:42

baemyung reviewed Apr 8, 2025

View reviewed changes

deepakala-k force-pushed the rebase_pretty_name branch from 27c9fde to 6f8a4dc Compare April 8, 2025 16:28

deepakala-k requested a review from baemyung April 8, 2025 16:28

baemyung approved these changes Apr 8, 2025

View reviewed changes

rfrandse merged commit 27363fb into ibm-openbmc:1120 Apr 9, 2025
1 check passed

baemyung mentioned this pull request Apr 11, 2025

Publish Location code under PCIeDevice schema (#1083) #1239

Merged

util: Add pretty name for resources (#918) #1201

util: Add pretty name for resources (#918) #1201

Uh oh!

Conversation

deepakala-k commented Mar 19, 2025

Uh oh!

gtmills commented Mar 19, 2025

Uh oh!

gtmills commented Mar 19, 2025

Uh oh!

gtmills commented Mar 19, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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!

deepakala-k commented Mar 20, 2025

Uh oh!

deepakala-k commented Mar 21, 2025

Uh oh!

baemyung commented Mar 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gtmills commented Mar 24, 2025

Uh oh!

deepakala-k commented Mar 24, 2025

Uh oh!

baemyung commented Mar 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

deepakala-k commented Apr 1, 2025

Uh oh!

baemyung commented Apr 1, 2025

Uh oh!

baemyung left a comment

Choose a reason for hiding this comment

Uh oh!

deepakala-k commented Apr 1, 2025

Uh oh!

baemyung commented Apr 1, 2025

Uh oh!

baemyung 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

baemyung commented Mar 24, 2025 •

edited

Loading

baemyung commented Mar 28, 2025 •

edited

Loading