Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BEAM-8430] Change py default sdk_worker_parallelism to 1 #9829

Merged
merged 1 commit into from Oct 21, 2019

Conversation

ibzib
Copy link
Contributor

@ibzib ibzib commented Oct 18, 2019

This aligns the Python SDK with the Java SDK.

R: @tweise @mxm @angoenka

Post-Commit Tests Status (on master branch)

Lang SDK Apex Dataflow Flink Gearpump Samza Spark
Go Build Status --- --- Build Status --- --- Build Status
Java Build Status Build Status Build Status Build Status
Build Status
Build Status
Build Status Build Status Build Status
Build Status
Python Build Status
Build Status
Build Status
Build Status
--- Build Status
Build Status
Build Status
Build Status
--- --- Build Status
XLang --- --- --- Build Status --- --- ---

Pre-Commit Tests Status (on master branch)

--- Java Python Go Website
Non-portable Build Status Build Status
Build Status
Build Status Build Status
Portable --- Build Status --- ---

See .test-infra/jenkins/README for trigger phrase, status and link of all Jenkins jobs.

@mxm
Copy link
Contributor

mxm commented Oct 18, 2019

Run Python2_PVR_Flink PreCommit

@tweise
Copy link
Contributor

tweise commented Oct 18, 2019

The mismatch actually goes back to f3623e8#diff-525d5d65bedd7ea5e6fce6e4cd57e153 and was masked by the job server option that got removed now.

Please also add a comment to PortableOptions that they need to remain in sync with the Java version.

Longer term it would be nice to define such options in proto.

This aligns the Python SDK with the Java SDK
@ibzib
Copy link
Contributor Author

ibzib commented Oct 21, 2019

@tweise I added a comment.

I agree that seems like a lot of extra work to manually maintain consistency between SDKs. It seems like the current options setup was designed to prioritize flexibility over structure.

@mxm
Copy link
Contributor

mxm commented Oct 21, 2019

Since we already have the option retrieval, we could leverage it to display the supported options from the Java SDK. However, it would be even better to have a language-agnostic option format which could be used by all SDKs to read from a single point of definition.

@mxm mxm merged commit 6df727b into apache:master Oct 21, 2019
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.

None yet

3 participants