Fix for Default service config not honored if initial name resolution fails #11368

vinodhabib · 2024-07-10T10:04:11Z

Fix for defect - #11040

… resolution fails

linux-foundation-easycla · 2024-07-10T10:04:15Z

The committers listed above are authorized under a signed CLA.

✅ login: vinodhabib (6887854, bc1280d, da35b39, 4f21d28, 9fe55c8, 8fa9bf2, b9b69d6, 9cf32e0, d161a46, 904b893, e40c233, 9d0c4ed, ea8e4bf, 77e3a03, 3a74aec, fe1e4a3, 0189312, e6c4244, fd75551, 70b9d22, b51a622, 17646e9, 6527440, 4fb9291, 9e6df97, 2f24bbf, 7b4a684, 137b200, 55ca70e, 747428e, 654ee02, c3f0579, 4337185, 1650896, 47b91c1, 989bec4, d311de5, 899f81a, d43ee65, bdadab6, b6e2809, b9735ba, 8f377b9)

core/src/test/java/io/grpc/internal/ManagedChannelImplTest.java

kannanjgithub · 2024-07-19T09:56:33Z

When you say not working, which part is not working? Did you add any test assertions and did they fail? Also what cases are the 3 scenarios you listed each for?

…

On Fri, Jul 19, 2024 at 2:49 PM Alam-Saran ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In core/src/test/java/io/grpc/internal/ManagedChannelImplTest.java <#11368 (comment)>: > @@ -4476,6 +4476,38 @@ public String getDefaultScheme() { } } + @test @kannanjgithub <https://github.com/kannanjgithub> Any further updates on the above. — Reply to this email directly, view it on GitHub <#11368 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHB2YHABPEGDPVE7HYJHPELZNDKYTAVCNFSM6AAAAABKUR6Q6GVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDCOBXG43TAOBRGU> . You are receiving this because you were mentioned.Message ID: <grpc/grpc-java/pull/11368/review/2187770815 ***@***.*** com>

Alam-Saran · 2024-07-19T10:55:28Z

When you say not working, which part is not working? Did you add any test assertions and did they fail? Also what cases are the 3 scenarios you listed each for?
…
On Fri, Jul 19, 2024 at 2:49 PM Alam-Saran @.> wrote: @.* commented on this pull request. ------------------------------ In core/src/test/java/io/grpc/internal/ManagedChannelImplTest.java <#11368 (comment)>: > @@ -4476,6 +4476,38 @@ public String getDefaultScheme() { } } + @test @kannanjgithub https://github.com/kannanjgithub Any further updates on the above. — Reply to this email directly, view it on GitHub <#11368 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHB2YHABPEGDPVE7HYJHPELZNDKYTAVCNFSM6AAAAABKUR6Q6GVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDCOBXG43TAOBRGU . You are receiving this because you were mentioned.Message ID: </pull/11368/review/2187770815 @.*** com>

none of the scenarios mentioned above are not going to our flow where we added applying the default service config change on Error.
As of now we have not added any assertions because its not calling our change.

kannanjgithub · 2024-07-22T12:40:10Z

I have asked a team member to look into this as I'm occupied with some tasks.

…

On Fri, Jul 19, 2024 at 4:25 PM Alam-Saran ***@***.***> wrote: When you say not working, which part is not working? Did you add any test assertions and did they fail? Also what cases are the 3 scenarios you listed each for? … <#m_-6234071685902259381_> On Fri, Jul 19, 2024 at 2:49 PM Alam-Saran *@*.*> wrote: @.** commented on this pull request. ------------------------------ In core/src/test/java/io/grpc/internal/ManagedChannelImplTest.java <#11368 (comment) <#11368 (comment)>>: > @@ -4476,6 +4476,38 @@ public String getDefaultScheme() { } } + @test <https://github.com/test> @kannanjgithub <https://github.com/kannanjgithub> https://github.com/kannanjgithub Any further updates on the above. — Reply to this email directly, view it on GitHub <#11368 (comment) <#11368 (comment)>>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHB2YHABPEGDPVE7HYJHPELZNDKYTAVCNFSM6AAAAABKUR6Q6GVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDCOBXG43TAOBRGU . You are receiving this because you were mentioned.Message ID: < /pull/11368 <#11368>/review/ 2187770815 <(218)%20777-0815> *@*.*** com> none of the scenarios mentioned above are not going to our flow where we added applying the default service config change on Error. As of now we have not added any assertions because its not calling our change. — Reply to this email directly, view it on GitHub <#11368 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHB2YHEV54KKY6XU35BZTGTZNDWDPAVCNFSM6AAAAABKUR6Q6GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZYHA4TOOJTGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

core/src/main/java/io/grpc/internal/ManagedChannelImpl.java

shivaspeaks · 2024-07-23T04:29:59Z

When you say not working, which part is not working? Did you add any test assertions and did they fail? Also what cases are the 3 scenarios you listed each for?
…
On Fri, Jul 19, 2024 at 2:49 PM Alam-Saran @.> wrote: _@**._* commented on this pull request. ------------------------------ In core/src/test/java/io/grpc/internal/ManagedChannelImplTest.java <#11368 (comment)>: > @@ -4476,6 +4476,38 @@ public String getDefaultScheme() { } } + @test @kannanjgithub https://github.com/kannanjgithub Any further updates on the above. — Reply to this email directly, view it on GitHub <#11368 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHB2YHABPEGDPVE7HYJHPELZNDKYTAVCNFSM6AAAAABKUR6Q6GVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDCOBXG43TAOBRGU . You are receiving this because you were mentioned.Message ID: </pull/11368/review/2187770815 _@_.* com>

none of the scenarios mentioned above are not going to our flow where we added applying the default service config change on Error. As of now we have not added any assertions because its not calling our change.

I did not completely understand the issue here, but on a high level I assume you're not able to call onError() method. Maybe you can try inducing error using Mockito and then verify.
As this is a unit test and we need line coverage here that it works properly in onError() method. Case would have been different had this been an integration test.

core/src/test/java/io/grpc/internal/ManagedChannelImplTest.java

core/src/main/java/io/grpc/internal/ManagedChannelImpl.java

kannanjgithub · 2024-08-07T12:38:28Z

It looks like it got stuck. Can you manually trigger the checks by pushing an empty commit?

git commit --allow-empty -m "Trigger Build"

vinodhabib · 2024-08-07T14:06:29Z

@kannanjgithub Still looks same after empty commit also

kannanjgithub · 2024-08-08T07:06:06Z

All checks have passed now. Please squash all commits into one using the 'Squash and merge' option. In the squashed commit change the commit title from "Fix for Default service config..." to a more meaningful "Use default service config if initial name resolution fails #11368".

vinodhabib · 2024-08-08T08:57:39Z

@kannanjgithub Looks like i don't have write access to merge the PR as its saying the same and don't see merge button as well.
not sure do i need any additional permission required here. please suggest.

kannanjgithub · 2024-08-08T09:51:42Z

I remembered only the repo maintainers have the merge access, so we can do it for you.
I also would like @ejona86 to approve the PR since he has also reviewed this PR before.

vinodhabib · 2024-08-09T13:38:43Z

@ejona86 Request you to do the needful on this PR

ejona86 · 2024-08-22T17:20:57Z

core/src/main/java/io/grpc/internal/ManagedChannelImpl.java

@@ -1840,6 +1841,13 @@ private void handleErrorInSyncContext(Status error) {
      if (NameResolverListener.this.helper != ManagedChannelImpl.this.lbHelper) {
        return;
      }
+      // Apply Default Service Config if initial name resolution fails.
+      if (lastServiceConfig == EMPTY_SERVICE_CONFIG && defaultServiceConfig != null) {


Yes, we initialize things to EMPTY_SERVICE_CONFIG, but we also use it after the initial resolution. And defaultServiceConfig != null shouldn't be relevant.

When we receive addresses but an invalid service config, we use do check whether there is a defaultServiceConfig. But if serverConfigError == null, then we still use EMPTY_SERVICE_CONFIG.

grpc-java/core/src/main/java/io/grpc/internal/ManagedChannelImpl.java

Lines 1748 to 1772 in 2fe1a13

} else if (defaultServiceConfig != null) {

effectiveServiceConfig = defaultServiceConfig;

realChannel.updateConfigSelector(effectiveServiceConfig.getDefaultConfigSelector());

channelLogger.log(

ChannelLogLevel.INFO,

"Received no service config, using default service config");

} else if (serviceConfigError != null) {

if (!serviceConfigUpdated) {

// First DNS lookup has invalid service config, and cannot fall back to default

channelLogger.log(

ChannelLogLevel.INFO,

"Fallback to error due to invalid first service config without default config");

// This error could be an "inappropriate" control plane error that should not bleed

// through to client code using gRPC. We let them flow through here to the LB as

// we later check for these error codes when investigating pick results in

// GrpcUtil.getTransportFromPickResult().

onError(configOrError.getError());

return configOrError.getError();

} else {

effectiveServiceConfig = lastServiceConfig;

}

} else {

effectiveServiceConfig = EMPTY_SERVICE_CONFIG;

realChannel.updateConfigSelector(null);

}

If serverConfigError != null then we go through onError() which triggers realChannel.onConfigError() just a few lines up in this method. onConfigError() however doesn't check defaultServiceConfig:

grpc-java/core/src/main/java/io/grpc/internal/ManagedChannelImpl.java

Lines 957 to 961 in 2fe1a13

void onConfigError() {

if (configSelector.get() == INITIAL_PENDING_SELECTOR) {

updateConfigSelector(null);

}

}

So I think the problem is "addresses + serviceConfigError" handles the default properly. But "address resolution error" ignores the defaultServiceConfig in RealChannel.onConfigError(). Looks like we should change onConfigError(), which is already doing proper checking to see if we've applied the service config already.

@ejona86 @kannanjgithub i understand 2 below points from your above comments, please confirm/suggest the same.

Point 1 : you mentioned in the below point the check defaultServiceConfig != null shouldn't be relevant as it will have default value so this check is not required here?
if (lastServiceConfig == EMPTY_SERVICE_CONFIG && defaultServiceConfig != null)

Point 2 : "address resolution error" ignores the defaultServiceConfig in RealChannel.onConfigError() ? needs to updated as below or need to add one more if condition to check this? not clear on this point?

void onConfigError() { if (configSelector.get() == INITIAL_PENDING_SELECTOR && defaultServiceConfig == null ) { updateConfigSelector(null); } }

So we already have this handling in NameResolverListener::onError (for address resolution errors) that ends up updating the config selector but with null.

NameResolverListener::onError -> NameResolverListener::handleErrorInSyncContext -> realChannel.onConfigError ->

if (configSelector.get() == INITIAL_PENDING_SELECTOR) { updateConfigSelector(null); }

So the call to update the config selector already exists (that we missed noticing), only it uses null always and doesn't use the defaultServiceConfig. If we just change here to

updateConfigSelector(defaultServiceConfig);

it would do. The check if (configSelector.get() == INITIAL_PENDING_SELECTOR) also already makes sure that the policy is only applied once, not on repeat invocations.

This means we didn't have to change anything in handleErrorInSyncContext. The other point was about the checks in that change for EMPTY_SERVICE_CONFIG was not correct but this value also gets assigned during a successful name resolution but with empty config, so our use of this value to mean that the config was never applied before was not correct. We need not continue discussion on this point since it turns out the code change in this method was not necessary to do.

@kannanjgithub As discussed in the call changes are in progress and let you know once its ready for review

@kannanjgithub code changes are done for the recent review points. please have a look once.
also updated the UT as per my current understanding which is covered as part of onError() flow as I don't see in the existing cases where they are covering the realChannel.onConfigError() directly as its private class.

There is ManagedChannelImpl::getConfigSelector() method that exposes its real channel's config selector. We should use this method and assert that it is same as the default service config. See example uses of this method in tests here.
Asserting for the config selector that gets set is important, asserting for channel trace events is secondary.

@kannanjgithub Review point fixed and Request you have a look once.
unable to cover line lastServiceConfig = defaultServiceConfig as its final class so unable to mock this behavior also I have seen this in the existing cases as no where directly called this its covered as part of onError() flow.

…nt Review points

Earlier set of changes was not the correct way to do as there was a call to onConfigError already in place.

kannanjgithub · 2024-09-17T06:47:00Z

core/src/test/java/io/grpc/internal/ManagedChannelImplTest.java

+      assertEquals(channel.getConfigSelector().getClass().getName(),
+          managedChannelServiceConfig.getDefaultConfigSelector().getClass().getName());
+      assertEquals(channel.getLastServiceConfig().toString(),
+          managedChannelServiceConfig.toString());


Said not to create a method to expose the last service config. Last service config is very much an implementation detail and should not be exposed.

kannanjgithub · 2024-09-17T06:48:11Z

core/src/test/java/io/grpc/internal/ManagedChannelImplTest.java

+
+      nameResolverFactory.resolvers.get(0).listener.onError(resolutionError);
+
+      assertEquals(channel.getConfigSelector().getClass().getName(),


This assertion is not needed, class names are set at compile time and it is impossible for them to change at runtime, so asserting them achieves nothing.

kannanjgithub · 2024-09-17T06:59:50Z

core/src/test/java/io/grpc/internal/ManagedChannelImplTest.java

+      channelBuilder.defaultServiceConfig(defaultServiceConfig);
+      ManagedChannelServiceConfig managedChannelServiceConfig =
+          createManagedChannelServiceConfig(defaultServiceConfig, null);
+      nameResolverFactory.nextConfigOrError.set(


What is the purpose of setting nextConfigOrError? I don't see it being used in the course of the test.

This will give the info like we are getting the defaultServiceConfig details which are internally setting to through ManagedChannelServiceConfig and setting this into nameResolverFactory which we are using below.

defaultServiceConfig -> ManagedChannelServiceConfig -> nameResolverFactory.nextConfigOrError.

do you thinks its not required? because I have seen some existing references similar to this in existing UT's in the same class.

If existing UTs are setting it they are using it. I don't see how your test uses it.

Fixed and Removed this setup/config step as it's not harming test flow.

kannanjgithub · 2024-09-17T07:02:45Z

core/src/test/java/io/grpc/internal/ManagedChannelImplTest.java

+      channelBuilder.defaultServiceConfig(defaultServiceConfig);
+      ManagedChannelServiceConfig managedChannelServiceConfig =
+          createManagedChannelServiceConfig(defaultServiceConfig, null);
+      nameResolverFactory.nextConfigOrError.set(


Same question here, doesn't seem to get used .

This will give the info like we are getting the defaultServiceConfig details which are internally setting to through ManagedChannelServiceConfig and setting this into nameResolverFactory which we are using below.

defaultServiceConfig -> ManagedChannelServiceConfig -> nameResolverFactory.nextConfigOrError.

do you thinks its not required? because I have seen some existing references similar to this in existing UT's in the same class.

Fixed and Removed this setup/config step as it's not harming test flow.

kannanjgithub · 2024-09-17T07:03:46Z

core/src/test/java/io/grpc/internal/ManagedChannelImplTest.java

+
+      // initial service config is already applied so it's not reapplied using the default service
+      // config here.
+      assertThat(getStats(channel).channelTrace.events).hasSize(prevSize + 2);


How does this assertion for prevSize + 2 fit in with the above comment? The comment seems to imply that the count should not have increased.

we need to delete this comment as it was added as part of previous implementation. I will delete it

defect-11040 - Fixed the default service config issue if initial name…

bc1280d

… resolution fails

vinodhabib mentioned this pull request Jul 10, 2024

Default service config not honored if initial name resolution fails #11040

Open

defect-11040 - Fixed checkstyle issue

6527440

kannanjgithub reviewed Jul 11, 2024

View reviewed changes

core/src/test/java/io/grpc/internal/ManagedChannelImplTest.java Show resolved Hide resolved

shivaspeaks reviewed Jul 23, 2024

View reviewed changes

core/src/main/java/io/grpc/internal/ManagedChannelImpl.java Outdated Show resolved Hide resolved

vinodhabib added 6 commits July 23, 2024 12:21

defect-11040 - Fixed Review point

fe1e4a3

defect-11040 - Fixed the Junit test and it's going to our change/flow.

77e3a03

defect-11040 - Fixed the check style issue.

3a74aec

defect-11040 - Fixed the check style issue.

e6c4244

defect-11040 - Fixed the check style issue.

55ca70e

defect-11040 - Fixed Review points.

904b893

kannanjgithub reviewed Jul 25, 2024

View reviewed changes

core/src/test/java/io/grpc/internal/ManagedChannelImplTest.java Show resolved Hide resolved

kannanjgithub reviewed Jul 25, 2024

View reviewed changes

core/src/test/java/io/grpc/internal/ManagedChannelImplTest.java Outdated Show resolved Hide resolved

kannanjgithub reviewed Jul 25, 2024

View reviewed changes

core/src/test/java/io/grpc/internal/ManagedChannelImplTest.java Outdated Show resolved Hide resolved

vinodhabib added 2 commits July 26, 2024 16:14

defect-11040 - Fixed Review points.

b51a622

Defect-11040 - Fixed Review points.

70b9d22

ejona86 reviewed Jul 29, 2024

View reviewed changes

core/src/main/java/io/grpc/internal/ManagedChannelImpl.java Outdated Show resolved Hide resolved

core/src/main/java/io/grpc/internal/ManagedChannelImpl.java Outdated Show resolved Hide resolved

vinodhabib added 3 commits July 30, 2024 12:38

Defect-11040 - Fixed Review points and moved the code as per suggestion.

d43ee65

Defect-11040 - Clarified the query and updated the code accordingly.

4fb9291

Defect-11040 - Clarified the query and updated the code accordingly.

e40c233

kannanjgithub reviewed Jul 30, 2024

View reviewed changes

core/src/main/java/io/grpc/internal/ManagedChannelImpl.java Outdated Show resolved Hide resolved

vinodhabib added 2 commits July 30, 2024 19:09

Defect-11040 - Fixed the Recent Review point for UT (Point 1)

4f21d28

Defect-11040 - Fixed the Recent Review point for UT (Point 2)

b9b69d6

kannanjgithub reviewed Jul 31, 2024

View reviewed changes

core/src/main/java/io/grpc/internal/ManagedChannelImpl.java Outdated Show resolved Hide resolved

kannanjgithub reviewed Jul 31, 2024

View reviewed changes

core/src/main/java/io/grpc/internal/ManagedChannelImpl.java Outdated Show resolved Hide resolved

Trigger Build

9d0c4ed

ejona86 added the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label Aug 7, 2024

grpc-kokoro removed the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label Aug 7, 2024

ejona86 reviewed Aug 22, 2024

View reviewed changes

vinodhabib added 6 commits August 23, 2024 14:09

Defect-11040 - Fixed Review points

0189312

Defect-11040 - Moved the code to onConfigError method as per the Rece…

bdadab6

…nt Review points

Merge branch 'master' into defect-11040-DefaultServiceConfigFix

989bec4

Defect-11040 - Updated the UT as per the recent Review fixes changes

c3f0579

Defect-11040 - Removed Annotation as it's not required now.

137b200

Defect-11040 - Fixed Recent Review points

d311de5

vinod-habib added 6 commits September 10, 2024 13:21

Defect-11040 - Added assert for data comparison

4337185

Defect-11040 - Added assert for data comparison

47b91c1

Defect-11040 - Added assert for data comparison

b9735ba

Defect-11040 - FixeReview points from Kannan received on Sept-16

654ee02

Defect-11040 - Fixed Review points from Kannan received on Sept-16

1650896

Defect-11040 - Fixed Review points from Kannan received on Sept-16

8f377b9

kannanjgithub reviewed Sep 17, 2024

View reviewed changes

vinod-habib added 2 commits September 17, 2024 08:11

Defect-11040 - Fixed Review points from Kannan received on Sept-17

b6e2809

Defect-11040 - Fixed Review points from Kannan received on Sept-17

899f81a

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix for Default service config not honored if initial name resolution fails #11368

Fix for Default service config not honored if initial name resolution fails #11368

vinodhabib commented Jul 10, 2024

linux-foundation-easycla bot commented Jul 10, 2024 •

edited

Loading

kannanjgithub commented Jul 19, 2024 via email

Alam-Saran commented Jul 19, 2024

kannanjgithub commented Jul 22, 2024 via email

shivaspeaks commented Jul 23, 2024

kannanjgithub commented Aug 7, 2024

vinodhabib commented Aug 7, 2024

kannanjgithub commented Aug 8, 2024

vinodhabib commented Aug 8, 2024 •

edited

Loading

kannanjgithub commented Aug 8, 2024

vinodhabib commented Aug 9, 2024

ejona86 Aug 22, 2024

vinodhabib Aug 23, 2024 •

edited

Loading

kannanjgithub Aug 23, 2024 •

edited

Loading

vinodhabib Aug 26, 2024 •

edited

Loading

vinodhabib Aug 29, 2024 •

edited

Loading

kannanjgithub Aug 30, 2024 •

edited

Loading

vinodhabib Sep 2, 2024

kannanjgithub Sep 17, 2024

kannanjgithub Sep 17, 2024

vinodhabib Sep 17, 2024

kannanjgithub Sep 17, 2024

vinodhabib Sep 17, 2024

kannanjgithub Sep 17, 2024

vinodhabib Sep 17, 2024

kannanjgithub Sep 17, 2024

vinodhabib Sep 17, 2024

vinodhabib Sep 17, 2024

kannanjgithub Sep 17, 2024

vinodhabib Sep 17, 2024 •

edited

Loading

vinodhabib Sep 17, 2024

	} else if (defaultServiceConfig != null) {
	effectiveServiceConfig = defaultServiceConfig;
	realChannel.updateConfigSelector(effectiveServiceConfig.getDefaultConfigSelector());
	channelLogger.log(
	ChannelLogLevel.INFO,
	"Received no service config, using default service config");
	} else if (serviceConfigError != null) {
	if (!serviceConfigUpdated) {
	// First DNS lookup has invalid service config, and cannot fall back to default
	channelLogger.log(
	ChannelLogLevel.INFO,
	"Fallback to error due to invalid first service config without default config");
	// This error could be an "inappropriate" control plane error that should not bleed
	// through to client code using gRPC. We let them flow through here to the LB as
	// we later check for these error codes when investigating pick results in
	// GrpcUtil.getTransportFromPickResult().
	onError(configOrError.getError());
	return configOrError.getError();
	} else {
	effectiveServiceConfig = lastServiceConfig;
	}
	} else {
	effectiveServiceConfig = EMPTY_SERVICE_CONFIG;
	realChannel.updateConfigSelector(null);
	}

	void onConfigError() {
	if (configSelector.get() == INITIAL_PENDING_SELECTOR) {
	updateConfigSelector(null);
	}
	}


		nameResolverFactory.resolvers.get(0).listener.onError(resolutionError);

		assertEquals(channel.getConfigSelector().getClass().getName(),

Fix for Default service config not honored if initial name resolution fails #11368

Are you sure you want to change the base?

Fix for Default service config not honored if initial name resolution fails #11368

Conversation

vinodhabib commented Jul 10, 2024

linux-foundation-easycla bot commented Jul 10, 2024 • edited Loading

kannanjgithub commented Jul 19, 2024 via email

Alam-Saran commented Jul 19, 2024

kannanjgithub commented Jul 22, 2024 via email

shivaspeaks commented Jul 23, 2024

kannanjgithub commented Aug 7, 2024

vinodhabib commented Aug 7, 2024

kannanjgithub commented Aug 8, 2024

vinodhabib commented Aug 8, 2024 • edited Loading

kannanjgithub commented Aug 8, 2024

vinodhabib commented Aug 9, 2024

Choose a reason for hiding this comment

vinodhabib Aug 23, 2024 • edited Loading

Choose a reason for hiding this comment

kannanjgithub Aug 23, 2024 • edited Loading

Choose a reason for hiding this comment

vinodhabib Aug 26, 2024 • edited Loading

Choose a reason for hiding this comment

vinodhabib Aug 29, 2024 • edited Loading

Choose a reason for hiding this comment

kannanjgithub Aug 30, 2024 • 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

vinodhabib Sep 17, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

linux-foundation-easycla bot commented Jul 10, 2024 •

edited

Loading

vinodhabib commented Aug 8, 2024 •

edited

Loading

vinodhabib Aug 23, 2024 •

edited

Loading

kannanjgithub Aug 23, 2024 •

edited

Loading

vinodhabib Aug 26, 2024 •

edited

Loading

vinodhabib Aug 29, 2024 •

edited

Loading

kannanjgithub Aug 30, 2024 •

edited

Loading

vinodhabib Sep 17, 2024 •

edited

Loading