[SPARK-32923][CORE][SHUFFLE] Handle indeterminate stage retries for push-based shuffle #33034

venkata91 · 2021-06-23T02:17:23Z

What changes were proposed in this pull request?

[SPARK-23243] and [SPARK-25341] addressed cases of stage retries for indeterminate stage involving operations like repartition. This PR addresses the same issues in the context of push-based shuffle. Currently there is no way to distinguish the current execution of a stage for a shuffle ID. Therefore the changes explained below are necessary.

Core changes are summarized as follows:

Introduce a new variable shuffleMergeId in ShuffleDependency which is monotonically increasing value tracking the temporal ordering of execution of <stage-id, stage-attempt-id> for a shuffle ID.
Correspondingly make changes in the push-based shuffle protocol layer in MergedShuffleFileManager, BlockStoreClient passing the shuffleMergeId in order to keep track of the shuffle output in separate files on the shuffle service side.
DAGScheduler increments the shuffleMergeId tracked in ShuffleDependency in the cases of a indeterministic stage execution
Deterministic stage will have shuffleMergeId set to 0 as no special handling is needed in this case and indeterminate stage will have shuffleMergeId starting from 1.

Why are the changes needed?

New protocol changes are needed due to the reasons explained above.

Does this PR introduce any user-facing change?

No

How was this patch tested?

Added new unit tests in RemoteBlockPushResolverSuite, DAGSchedulerSuite, BlockIdSuite, ErrorHandlerSuite

venkata91 · 2021-06-23T02:19:59Z

cc @mridulm @Victsm @otterc @zhouyejoe @Ngone51 Please take a look. Currently it is in work in progress as tests are being added. Raised this PR now since we are making protocol changes, it would be better if it can be done before branch-3.2 cut that way at least protocol changes can be merged if reviews on implementation details takes more time. Thanks :)

mridulm

We need to handle the case of how shuffleSequenceId needs to be configured.

core/src/main/scala/org/apache/spark/Dependency.scala

core/src/main/scala/org/apache/spark/scheduler/DAGScheduler.scala

common/network-common/src/main/java/org/apache/spark/network/client/TransportClient.java

otterc

Changes to fetch protocols seem unnecessary because fetch will never request shuffle data of an older shuffleSequenceId.

...n/network-common/src/main/java/org/apache/spark/network/protocol/MergedBlockMetaRequest.java

common/network-shuffle/src/main/java/org/apache/spark/network/shuffle/ExternalBlockHandler.java

.../network-shuffle/src/main/java/org/apache/spark/network/shuffle/RemoteBlockPushResolver.java

mridulm

Some more comments

core/src/main/scala/org/apache/spark/Dependency.scala

...ffle/src/main/java/org/apache/spark/network/shuffle/protocol/AbstractFetchShuffleBlocks.java

...work-shuffle/src/main/java/org/apache/spark/network/shuffle/protocol/FetchShuffleBlocks.java

venkata91 · 2021-07-19T19:23:06Z

@mridulm @otterc @Ngone51 Currently I have updated the PR with the changes of SPARK-35546, will remove it once the PR gets merged. Please review.

...on/network-shuffle/src/main/java/org/apache/spark/network/shuffle/OneForOneBlockFetcher.java

venkata91 · 2021-07-20T19:19:32Z

@otterc feels this PR is quite big, I agree. I will break this PR in to 2 client and server and keep this for reference purposes.

core/src/main/scala/org/apache/spark/MapOutputTracker.scala

mridulm · 2021-07-21T02:20:18Z

Is this still WIP ?

venkata91 · 2021-07-21T02:24:39Z

Is this still WIP ?

Yeah I am in the process of breaking this into 2 PRs. Will update here once that is done.

venkata91 · 2021-07-21T17:10:39Z

Is this still WIP ?

Yeah I am in the process of breaking this into 2 PRs. Will update here once that is done.

After having offline discussions with @mridulm , we decided not to break this PR in to 2. Will fix one of the pending change and remove the WIP tag.

otterc · 2021-07-21T17:42:39Z

After having offline discussions with @mridulm , we decided not to break this PR in to 2. Will fix one of the pending change and remove the WIP tag.

@venkata91 Could you please provide a reason for not breaking this PR in multiple parts. This PR is touching a lot files both on the client and server side. It changes the protocols. On the client, this again touches the driver side, the push side, and the fetch side.
We have broken changes in the past for similar sized changes to make the review easy and reduces the introduction of bugs. So why for this one we are making the exception?
cc. @mridulm @Victsm @Ngone51

venkata91 · 2021-07-21T18:08:21Z

After having offline discussions with @mridulm , we decided not to break this PR in to 2. Will fix one of the pending change and remove the WIP tag.

@venkata91 Could you please provide a reason for not breaking this PR in multiple parts. This PR is touching a lot files both on the client and server side. It changes the protocols. On the client, this again touches the driver side, the push side, and the fetch side.
We have broken changes in the past for similar sized changes to make the review easy and reduces the introduction of bugs. So why for this one we are making the exception?
cc. @mridulm @Victsm @Ngone51
There are couple of reasons:

Splitting the PR into 2 is not easy as well as clean - there are few classes which are dependent on both client and server side for eg: MergeStatuses, FinalizeShuffleMerge and if I start adding one of them to either client side changes or server side changes then the dependencies slowly expand and becomes hard to separate them into 2 clean units given now we have implementation also in place.
Given the timeline of RC, @mridulm feels if we break this in to 2 and 1 of them gets in but the other don't then that would be a problem. May be we can time it out so that both of them are close to completion and try to merge them both together.
Any suggestions?

venkata91 · 2021-07-21T19:42:26Z

@mridulm Removed the WIP tag now it is good to review. cc @Victsm @otterc @Ngone51

Ngone51 · 2021-07-22T01:30:46Z

I tend to agree with not break because of the RC timeline. Usually, multiple PRs take more time to get all merged in than one PR.
I'll take a look today.

venkata91 · 2021-08-01T18:35:26Z

Can you fix the conflict @venkata91 ?

@mridulm Fixed the conflict, should be good now. Will wait for the tests to run completely.

SparkQA · 2021-08-01T19:26:58Z

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/46442/

SparkQA · 2021-08-01T20:00:59Z

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/46442/

SparkQA · 2021-08-01T21:10:00Z

Test build #141932 has finished for PR 33034 at commit 4a43d1d.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

mridulm · 2021-08-01T22:45:15Z

Thanks @venkata91, the tests are passing with the update.
The PR has addressed all pending comment, but will wait for @Ngone51, @otterc or @zhouyejoe to also take a look before merging.

.../network-shuffle/src/main/java/org/apache/spark/network/shuffle/RemoteBlockPushResolver.java

zhouyejoe · 2021-08-02T02:14:55Z

@venkata91 Thanks for working on this. LGTM.

.../network-shuffle/src/main/java/org/apache/spark/network/shuffle/RemoteBlockPushResolver.java

…ush-based shuffle [[SPARK-23243](https://issues.apache.org/jira/browse/SPARK-23243)] and [[SPARK-25341](https://issues.apache.org/jira/browse/SPARK-25341)] addressed cases of stage retries for indeterminate stage involving operations like repartition. This PR addresses the same issues in the context of push-based shuffle. Currently there is no way to distinguish the current execution of a stage for a shuffle ID. Therefore the changes explained below are necessary. Core changes are summarized as follows: 1. Introduce a new variable `shuffleMergeId` in `ShuffleDependency` which is monotonically increasing value tracking the temporal ordering of execution of <stage-id, stage-attempt-id> for a shuffle ID. 2. Correspondingly make changes in the push-based shuffle protocol layer in `MergedShuffleFileManager`, `BlockStoreClient` passing the `shuffleMergeId` in order to keep track of the shuffle output in separate files on the shuffle service side. 3. `DAGScheduler` increments the `shuffleMergeId` tracked in `ShuffleDependency` in the cases of a indeterministic stage execution 4. Deterministic stage will have `shuffleMergeId` set to 0 as no special handling is needed in this case and indeterminate stage will have `shuffleMergeId` starting from 1. New protocol changes are needed due to the reasons explained above. No Added new unit tests in `RemoteBlockPushResolverSuite, DAGSchedulerSuite, BlockIdSuite, ErrorHandlerSuite` Closes #33034 from venkata91/SPARK-32923. Authored-by: Venkata krishnan Sowrirajan <vsowrirajan@linkedin.com> Signed-off-by: Mridul Muralidharan <mridul<at>gmail.com> (cherry picked from commit c039d99) Signed-off-by: Mridul Muralidharan <mridulatgmail.com>

mridulm · 2021-08-02T04:32:03Z

Merged to master and branch-3.2
There was some conflict cherry picking to branch-3.2 which I manually fixed.

+CC @gengliangwang

Thanks for fixing this @venkata91
Thanks for all the reviews @Ngone51, @otterc, @zhouyejoe and @Victsm !

This was the last patch for push based shuffle SPIP - the only pending task is documentation.
Thanks for all the PR's and reviews everyone !!

gengliangwang · 2021-08-02T04:37:25Z

@venkata91 Thanks for the work!
@mridulm Thanks for the ping :)

venkata91 · 2021-08-02T05:03:38Z

Thanks for the thorough reviews @mridulm @Ngone51 @otterc @zhouyejoe . Learned quite a lot :)

…ush-based shuffle [[SPARK-23243](https://issues.apache.org/jira/browse/SPARK-23243)] and [[SPARK-25341](https://issues.apache.org/jira/browse/SPARK-25341)] addressed cases of stage retries for indeterminate stage involving operations like repartition. This PR addresses the same issues in the context of push-based shuffle. Currently there is no way to distinguish the current execution of a stage for a shuffle ID. Therefore the changes explained below are necessary. Core changes are summarized as follows: 1. Introduce a new variable `shuffleMergeId` in `ShuffleDependency` which is monotonically increasing value tracking the temporal ordering of execution of <stage-id, stage-attempt-id> for a shuffle ID. 2. Correspondingly make changes in the push-based shuffle protocol layer in `MergedShuffleFileManager`, `BlockStoreClient` passing the `shuffleMergeId` in order to keep track of the shuffle output in separate files on the shuffle service side. 3. `DAGScheduler` increments the `shuffleMergeId` tracked in `ShuffleDependency` in the cases of a indeterministic stage execution 4. Deterministic stage will have `shuffleMergeId` set to 0 as no special handling is needed in this case and indeterminate stage will have `shuffleMergeId` starting from 1. New protocol changes are needed due to the reasons explained above. No Added new unit tests in `RemoteBlockPushResolverSuite, DAGSchedulerSuite, BlockIdSuite, ErrorHandlerSuite` Closes apache#33034 from venkata91/SPARK-32923. Authored-by: Venkata krishnan Sowrirajan <vsowrirajan@linkedin.com> Signed-off-by: Mridul Muralidharan <mridul<at>gmail.com> (cherry picked from commit c039d99)

…when finalize request for higher shuffleMergeId is received ### What changes were proposed in this pull request? Clean up older shuffleMergeId shuffle files when finalize request for higher shuffleMergeId is received when no blocks pushed for the corresponding shuffleMergeId. This is identified as part of #33034 (comment). ### Why are the changes needed? Without this change, older shuffleMergeId files won't be cleaned up properly. ### Does this PR introduce _any_ user-facing change? No ### How was this patch tested? Added changes to existing unit test to address this case. Closes #33605 from venkata91/SPARK-32923-follow-on. Authored-by: Venkata krishnan Sowrirajan <vsowrirajan@linkedin.com> Signed-off-by: Mridul Muralidharan <mridul<at>gmail.com>

…when finalize request for higher shuffleMergeId is received ### What changes were proposed in this pull request? Clean up older shuffleMergeId shuffle files when finalize request for higher shuffleMergeId is received when no blocks pushed for the corresponding shuffleMergeId. This is identified as part of #33034 (comment). ### Why are the changes needed? Without this change, older shuffleMergeId files won't be cleaned up properly. ### Does this PR introduce _any_ user-facing change? No ### How was this patch tested? Added changes to existing unit test to address this case. Closes #33605 from venkata91/SPARK-32923-follow-on. Authored-by: Venkata krishnan Sowrirajan <vsowrirajan@linkedin.com> Signed-off-by: Mridul Muralidharan <mridul<at>gmail.com> (cherry picked from commit d816949) Signed-off-by: Mridul Muralidharan <mridulatgmail.com>

### What changes were proposed in this pull request? Cleanup `RemoteBlockPushResolver` log messages by using `AppShufflePartitionInfo#toString()` to avoid duplications. Currently this is based off of #33034 will remove those changes once it is merged and remove the WIP at that time. ### Why are the changes needed? Minor cleanup to make code more readable. ### Does this PR introduce _any_ user-facing change? No ### How was this patch tested? No tests, just changing log messages Closes #33561 from venkata91/SPARK-36332. Authored-by: Venkata krishnan Sowrirajan <vsowrirajan@linkedin.com> Signed-off-by: yi.wu <yi.wu@databricks.com>

### What changes were proposed in this pull request? Cleanup `RemoteBlockPushResolver` log messages by using `AppShufflePartitionInfo#toString()` to avoid duplications. Currently this is based off of #33034 will remove those changes once it is merged and remove the WIP at that time. ### Why are the changes needed? Minor cleanup to make code more readable. ### Does this PR introduce _any_ user-facing change? No ### How was this patch tested? No tests, just changing log messages Closes #33561 from venkata91/SPARK-36332. Authored-by: Venkata krishnan Sowrirajan <vsowrirajan@linkedin.com> Signed-off-by: yi.wu <yi.wu@databricks.com> (cherry picked from commit ab89710) Signed-off-by: yi.wu <yi.wu@databricks.com>

…ush-based shuffle [[SPARK-23243](https://issues.apache.org/jira/browse/SPARK-23243)] and [[SPARK-25341](https://issues.apache.org/jira/browse/SPARK-25341)] addressed cases of stage retries for indeterminate stage involving operations like repartition. This PR addresses the same issues in the context of push-based shuffle. Currently there is no way to distinguish the current execution of a stage for a shuffle ID. Therefore the changes explained below are necessary. Core changes are summarized as follows: 1. Introduce a new variable `shuffleMergeId` in `ShuffleDependency` which is monotonically increasing value tracking the temporal ordering of execution of <stage-id, stage-attempt-id> for a shuffle ID. 2. Correspondingly make changes in the push-based shuffle protocol layer in `MergedShuffleFileManager`, `BlockStoreClient` passing the `shuffleMergeId` in order to keep track of the shuffle output in separate files on the shuffle service side. 3. `DAGScheduler` increments the `shuffleMergeId` tracked in `ShuffleDependency` in the cases of a indeterministic stage execution 4. Deterministic stage will have `shuffleMergeId` set to 0 as no special handling is needed in this case and indeterminate stage will have `shuffleMergeId` starting from 1. New protocol changes are needed due to the reasons explained above. No Added new unit tests in `RemoteBlockPushResolverSuite, DAGSchedulerSuite, BlockIdSuite, ErrorHandlerSuite` Closes apache#33034 from venkata91/SPARK-32923. Authored-by: Venkata krishnan Sowrirajan <vsowrirajan@linkedin.com> Signed-off-by: Mridul Muralidharan <mridul<at>gmail.com> (cherry picked from commit c039d99) Signed-off-by: Mridul Muralidharan <mridulatgmail.com>

…when finalize request for higher shuffleMergeId is received ### What changes were proposed in this pull request? Clean up older shuffleMergeId shuffle files when finalize request for higher shuffleMergeId is received when no blocks pushed for the corresponding shuffleMergeId. This is identified as part of apache#33034 (comment). ### Why are the changes needed? Without this change, older shuffleMergeId files won't be cleaned up properly. ### Does this PR introduce _any_ user-facing change? No ### How was this patch tested? Added changes to existing unit test to address this case. Closes apache#33605 from venkata91/SPARK-32923-follow-on. Authored-by: Venkata krishnan Sowrirajan <vsowrirajan@linkedin.com> Signed-off-by: Mridul Muralidharan <mridul<at>gmail.com> (cherry picked from commit d816949) Signed-off-by: Mridul Muralidharan <mridulatgmail.com>

…ush-based shuffle [[SPARK-23243](https://issues.apache.org/jira/browse/SPARK-23243)] and [[SPARK-25341](https://issues.apache.org/jira/browse/SPARK-25341)] addressed cases of stage retries for indeterminate stage involving operations like repartition. This PR addresses the same issues in the context of push-based shuffle. Currently there is no way to distinguish the current execution of a stage for a shuffle ID. Therefore the changes explained below are necessary. Core changes are summarized as follows: 1. Introduce a new variable `shuffleMergeId` in `ShuffleDependency` which is monotonically increasing value tracking the temporal ordering of execution of <stage-id, stage-attempt-id> for a shuffle ID. 2. Correspondingly make changes in the push-based shuffle protocol layer in `MergedShuffleFileManager`, `BlockStoreClient` passing the `shuffleMergeId` in order to keep track of the shuffle output in separate files on the shuffle service side. 3. `DAGScheduler` increments the `shuffleMergeId` tracked in `ShuffleDependency` in the cases of a indeterministic stage execution 4. Deterministic stage will have `shuffleMergeId` set to 0 as no special handling is needed in this case and indeterminate stage will have `shuffleMergeId` starting from 1. New protocol changes are needed due to the reasons explained above. No Added new unit tests in `RemoteBlockPushResolverSuite, DAGSchedulerSuite, BlockIdSuite, ErrorHandlerSuite` Closes #33034 from venkata91/SPARK-32923. Authored-by: Venkata krishnan Sowrirajan <vsowrirajan@linkedin.com> Signed-off-by: Mridul Muralidharan <mridul<at>gmail.com>

…when finalize request for higher shuffleMergeId is received ### What changes were proposed in this pull request? Clean up older shuffleMergeId shuffle files when finalize request for higher shuffleMergeId is received when no blocks pushed for the corresponding shuffleMergeId. This is identified as part of #33034 (comment). ### Why are the changes needed? Without this change, older shuffleMergeId files won't be cleaned up properly. ### Does this PR introduce _any_ user-facing change? No ### How was this patch tested? Added changes to existing unit test to address this case. Closes #33605 from venkata91/SPARK-32923-follow-on. Authored-by: Venkata krishnan Sowrirajan <vsowrirajan@linkedin.com> Signed-off-by: Mridul Muralidharan <mridul<at>gmail.com>

venkata91 force-pushed the SPARK-32923 branch 2 times, most recently from de08b6e to 39e5df6 Compare June 23, 2021 02:35

mridulm reviewed Jun 23, 2021

View reviewed changes

core/src/main/scala/org/apache/spark/Dependency.scala Outdated Show resolved Hide resolved

core/src/main/scala/org/apache/spark/Dependency.scala Show resolved Hide resolved

core/src/main/scala/org/apache/spark/scheduler/DAGScheduler.scala Outdated Show resolved Hide resolved

otterc reviewed Jun 23, 2021

View reviewed changes

common/network-common/src/main/java/org/apache/spark/network/client/TransportClient.java Outdated Show resolved Hide resolved

otterc reviewed Jun 23, 2021

View reviewed changes

mridulm reviewed Jun 28, 2021

View reviewed changes

core/src/main/scala/org/apache/spark/Dependency.scala Outdated Show resolved Hide resolved

core/src/main/scala/org/apache/spark/Dependency.scala Show resolved Hide resolved

mridulm mentioned this pull request Jun 28, 2021

[WIP][SPARK-35917][SHUFFLE][CORE]Disable push-based shuffle feature to prevent it from being used #33118

Closed

otterc mentioned this pull request Jun 29, 2021

[SPARK-32922][SHUFFLE][CORE] Adds support for executors to fetch local and remote merged shuffle data #32140

Closed

venkata91 requested a review from Ngone51 June 29, 2021 17:16

otterc suggested changes Jun 30, 2021

View reviewed changes

...ffle/src/main/java/org/apache/spark/network/shuffle/protocol/AbstractFetchShuffleBlocks.java Outdated Show resolved Hide resolved

...work-shuffle/src/main/java/org/apache/spark/network/shuffle/protocol/FetchShuffleBlocks.java Outdated Show resolved Hide resolved

otterc mentioned this pull request Jun 30, 2021

[SPARK-35546][Shuffle] Enable push-based shuffle when multiple app attempts are enabled and manage concurrent access to the state in a better way #33078

Closed

otterc mentioned this pull request Jul 14, 2021

[WIP][SPARK-35917][SHUFFLE][CORE][3.2] Disable push-based shuffle feature to prevent it from being used #33329

Closed

venkata91 force-pushed the SPARK-32923 branch from 39e5df6 to b197cc5 Compare July 19, 2021 19:21

github-actions bot added the CORE label Jul 19, 2021

venkata91 force-pushed the SPARK-32923 branch 2 times, most recently from 6e21a27 to 92ada56 Compare July 19, 2021 20:04

venkata91 commented Jul 19, 2021

View reviewed changes

...on/network-shuffle/src/main/java/org/apache/spark/network/shuffle/OneForOneBlockFetcher.java Outdated Show resolved Hide resolved

venkata91 force-pushed the SPARK-32923 branch from 92ada56 to e443706 Compare July 20, 2021 05:40

otterc reviewed Jul 20, 2021

View reviewed changes

core/src/main/scala/org/apache/spark/MapOutputTracker.scala Outdated Show resolved Hide resolved

venkata91 changed the title ~~WIP: [SPARK-32923][CORE][SHUFFLE] Handle indeterminate stage retries for push-based shuffle~~ [SPARK-32923][CORE][SHUFFLE] Handle indeterminate stage retries for push-based shuffle Jul 21, 2021

Address mridulm, ngone51, zhouyejoe review comments

4a43d1d

venkata91 force-pushed the SPARK-32923 branch from fa706e0 to 4a43d1d Compare August 1, 2021 18:35

Ngone51 reviewed Aug 2, 2021

View reviewed changes

.../network-shuffle/src/main/java/org/apache/spark/network/shuffle/RemoteBlockPushResolver.java Show resolved Hide resolved

Ngone51 approved these changes Aug 2, 2021

View reviewed changes

zhouyejoe approved these changes Aug 2, 2021

View reviewed changes

mridulm reviewed Aug 2, 2021

View reviewed changes

.../network-shuffle/src/main/java/org/apache/spark/network/shuffle/RemoteBlockPushResolver.java Show resolved Hide resolved

mridulm reviewed Aug 2, 2021

View reviewed changes

.../network-shuffle/src/main/java/org/apache/spark/network/shuffle/RemoteBlockPushResolver.java Show resolved Hide resolved

asfgit closed this in c039d99 Aug 2, 2021

mridulm mentioned this pull request Aug 2, 2021

[SPARK-36206][CORE] Support shuffle data corruption diagnosis via shuffle checksum #33451

Closed

venkata91 mentioned this pull request Aug 2, 2021

[SPARK-32923][FOLLOW-UP] Clean up older shuffleMergeId shuffle files when finalize request for higher shuffleMergeId is received #33605

Closed

venkata91 mentioned this pull request Aug 4, 2021

[SPARK-36378][SHUFFLE] Switch to using RPCResponse to communicate common block push failures to the client. #33613

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[SPARK-32923][CORE][SHUFFLE] Handle indeterminate stage retries for push-based shuffle #33034

[SPARK-32923][CORE][SHUFFLE] Handle indeterminate stage retries for push-based shuffle #33034

venkata91 commented Jun 23, 2021 •

edited

Loading

venkata91 commented Jun 23, 2021

mridulm left a comment

otterc left a comment

mridulm left a comment

venkata91 commented Jul 19, 2021

venkata91 commented Jul 20, 2021

mridulm commented Jul 21, 2021

venkata91 commented Jul 21, 2021

venkata91 commented Jul 21, 2021

otterc commented Jul 21, 2021 •

edited

Loading

venkata91 commented Jul 21, 2021

venkata91 commented Jul 21, 2021 •

edited

Loading

Ngone51 commented Jul 22, 2021

venkata91 commented Aug 1, 2021 •

edited

Loading

SparkQA commented Aug 1, 2021

SparkQA commented Aug 1, 2021

SparkQA commented Aug 1, 2021

mridulm commented Aug 1, 2021

zhouyejoe commented Aug 2, 2021

mridulm commented Aug 2, 2021

gengliangwang commented Aug 2, 2021

venkata91 commented Aug 2, 2021

[SPARK-32923][CORE][SHUFFLE] Handle indeterminate stage retries for push-based shuffle #33034

[SPARK-32923][CORE][SHUFFLE] Handle indeterminate stage retries for push-based shuffle #33034

Conversation

venkata91 commented Jun 23, 2021 • edited Loading

What changes were proposed in this pull request?

Why are the changes needed?

Does this PR introduce any user-facing change?

How was this patch tested?

venkata91 commented Jun 23, 2021

mridulm left a comment

Choose a reason for hiding this comment

otterc left a comment

Choose a reason for hiding this comment

mridulm left a comment

Choose a reason for hiding this comment

venkata91 commented Jul 19, 2021

venkata91 commented Jul 20, 2021

mridulm commented Jul 21, 2021

venkata91 commented Jul 21, 2021

venkata91 commented Jul 21, 2021

otterc commented Jul 21, 2021 • edited Loading

venkata91 commented Jul 21, 2021

venkata91 commented Jul 21, 2021 • edited Loading

Ngone51 commented Jul 22, 2021

venkata91 commented Aug 1, 2021 • edited Loading

SparkQA commented Aug 1, 2021

SparkQA commented Aug 1, 2021

SparkQA commented Aug 1, 2021

mridulm commented Aug 1, 2021

zhouyejoe commented Aug 2, 2021

mridulm commented Aug 2, 2021

gengliangwang commented Aug 2, 2021

venkata91 commented Aug 2, 2021

venkata91 commented Jun 23, 2021 •

edited

Loading

otterc commented Jul 21, 2021 •

edited

Loading

venkata91 commented Jul 21, 2021 •

edited

Loading

venkata91 commented Aug 1, 2021 •

edited

Loading