Skip to content

[SPARK-59702][K8S][4.X] Use KeyToPathBuilder instead of KeyToPath constructor - #58954

Closed
dongjoon-hyun wants to merge 1 commit into
apache:branch-4.xfrom
dongjoon-hyun:SPARK-59702
Closed

dongjoon-hyun wants to merge 1 commit into
apache:branch-4.xfrom
dongjoon-hyun:SPARK-59702

Conversation

@dongjoon-hyun

Copy link
Copy Markdown
Member

What changes were proposed in this pull request?

This PR aims to use the fluent KeyToPathBuilder instead of the positional KeyToPath constructor in KubernetesClientUtils and ClientSuite.

Why are the changes needed?

KeyToPath gains new fields as new Kubernetes versions are supported, and each addition changes the canonical constructor signature and breaks compilation. The builder names every field it sets and is already the prevailing style in this module (e.g. HadoopConfDriverFeatureStep, KerberosConfDriverFeatureStep).

Does this PR introduce any user-facing change?

No. The builder produces the same KeyToPath objects as before.

How was this patch tested?

Pass the CIs.

Was this patch authored or co-authored using generative AI tooling?

Generated-by: Claude Opus 5

@dongjoon-hyun

Copy link
Copy Markdown
Member Author

Thank you, @HyukjinKwon . 😄

dongjoon-hyun added a commit that referenced this pull request Sep 22, 2026
… constructor

### What changes were proposed in this pull request?

This PR aims to use the fluent `KeyToPathBuilder` instead of the positional `KeyToPath` constructor in `KubernetesClientUtils` and `ClientSuite`.

### Why are the changes needed?

`KeyToPath` gains new fields as new Kubernetes versions are supported, and each addition changes the canonical constructor signature and breaks compilation. The builder names every field it sets and is already the prevailing style in this module (e.g. `HadoopConfDriverFeatureStep`, `KerberosConfDriverFeatureStep`).

### Does this PR introduce _any_ user-facing change?

No. The builder produces the same `KeyToPath` objects as before.

### How was this patch tested?

Pass the CIs.

### Was this patch authored or co-authored using generative AI tooling?

Generated-by: Claude Opus 5

Closes #58954 from dongjoon-hyun/SPARK-59702.

Authored-by: Dongjoon Hyun <dongjoon@apache.org>
Signed-off-by: Dongjoon Hyun <dongjoon@apache.org>
@dongjoon-hyun

Copy link
Copy Markdown
Member Author

Merge Summary:

Posted by merge_spark_pr.py

dongjoon-hyun added a commit that referenced this pull request Sep 22, 2026
… constructor

This PR aims to use the fluent `KeyToPathBuilder` instead of the positional `KeyToPath` constructor in `KubernetesClientUtils` and `ClientSuite`.

`KeyToPath` gains new fields as new Kubernetes versions are supported, and each addition changes the canonical constructor signature and breaks compilation. The builder names every field it sets and is already the prevailing style in this module (e.g. `HadoopConfDriverFeatureStep`, `KerberosConfDriverFeatureStep`).

No. The builder produces the same `KeyToPath` objects as before.

Pass the CIs.

Generated-by: Claude Opus 5

Closes #58954 from dongjoon-hyun/SPARK-59702.

Authored-by: Dongjoon Hyun <dongjoon@apache.org>
Signed-off-by: Dongjoon Hyun <dongjoon@apache.org>
(cherry picked from commit d9c20f6)
Signed-off-by: Dongjoon Hyun <dongjoon@apache.org>
@dongjoon-hyun

Copy link
Copy Markdown
Member Author

I backported this to branch-4.3 too.

@dongjoon-hyun
dongjoon-hyun deleted the SPARK-59702 branch September 22, 2026 00:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants