Skip to content

feat(glue-alpha): pair workerType and numberOfWorkers into a required workerConfiguration - #38576

Open
otaviomacedo wants to merge 2 commits into
mainfrom
otaviom/glue/worker-configuration
Open

feat(glue-alpha): pair workerType and numberOfWorkers into a required workerConfiguration#38576
otaviomacedo wants to merge 2 commits into
mainfrom
otaviom/glue/worker-configuration

Conversation

@otaviomacedo

Copy link
Copy Markdown
Contributor

Worker sizing was modeled as two independent optional props (workerType, numberOfWorkers) on the base JobProps. This let subtypes that cannot honor them inherit them (PythonShellJob dropped them silently; RayJob accepted workerType only to reject anything but Z.2X), and left the pair's co-dependency validated in only two of the six Spark job types, with two different error codes.

Move the pair onto a WorkerConfiguration value object exposed as the optional workerConfiguration prop on SparkJobProps, so a Spark job can never be given one field without the other -- the illegal state is now a compile error instead of a synth-time throw, and the duplicated/divergent validation is removed. Remove workerType/numberOfWorkers from the base JobProps: PythonShellJob (DPU-sized via maxCapacity) no longer surfaces them, and RayJob keeps its own numberOfWorkers while dropping the fixed-value workerType.

BREAKING CHANGE: workerType and numberOfWorkers are no longer top-level job props. For Spark jobs, pass them together via workerConfiguration: { workerType, numberOfWorkers }. PythonShellJob no longer accepts them (it is sized by maxCapacity). RayJob no longer accepts workerType (it is fixed to Z.2X).


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

… workerConfiguration

Worker sizing was modeled as two independent optional props (workerType,
numberOfWorkers) on the base JobProps. This let subtypes that cannot honor them
inherit them (PythonShellJob dropped them silently; RayJob accepted workerType
only to reject anything but Z.2X), and left the pair's co-dependency validated in
only two of the six Spark job types, with two different error codes.

Move the pair onto a WorkerConfiguration value object exposed as the optional
workerConfiguration prop on SparkJobProps, so a Spark job can never be given one
field without the other -- the illegal state is now a compile error instead of a
synth-time throw, and the duplicated/divergent validation is removed. Remove
workerType/numberOfWorkers from the base JobProps: PythonShellJob (DPU-sized via
maxCapacity) no longer surfaces them, and RayJob keeps its own numberOfWorkers
while dropping the fixed-value workerType.

Addresses the two workerType/numberOfWorkers findings from the aws-glue-alpha
pre-GA API review.

BREAKING CHANGE: workerType and numberOfWorkers are no longer top-level job props.
For Spark jobs, pass them together via workerConfiguration: { workerType,
numberOfWorkers }. PythonShellJob no longer accepts them (it is sized by
maxCapacity). RayJob no longer accepts workerType (it is fixed to Z.2X).
@github-actions github-actions Bot added the p2 label Aug 17, 2026
@aws-cdk-automation
aws-cdk-automation requested a review from a team August 17, 2026 09:26
@mergify mergify Bot added the contribution/core This is a PR that came from AWS. label Aug 17, 2026
@mergify
mergify Bot deployed to automation August 17, 2026 09:27 Active
@mergify
mergify Bot deployed to automation August 17, 2026 09:28 Active
@github-actions

Copy link
Copy Markdown
Contributor

⚠️ This pull request description does not follow the correct template structure.

PRs without a linked issue will receive lower priority for review and merging. Please update the description to follow the PR template and include a line like Closes #123 in the Issue section. If no existing issue matches your change, create one first.

@aws-cdk-automation aws-cdk-automation left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(This review is outdated)

@otaviomacedo otaviomacedo added the pr-linter/exempt-integ-test The PR linter will not require integ test changes label Aug 17, 2026
@aws-cdk-automation
aws-cdk-automation dismissed their stale review August 17, 2026 09:39

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

Comment on lines -352 to -361
readonly numberOfWorkers?: number;

/**
* Worker Type (optional)
* Type of Worker for Glue to use during job execution
* Enum options: Standard, G_1X, G_2X, G_025X. G_4X, G_8X, Z_2X
*
* @default WorkerType.G_1X
*/
readonly workerType?: WorkerType;

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Replaced with WorkerConfiguration.

*
* @default - the job runs with the G_1X worker type and 10 workers.
*/
readonly workerConfiguration?: WorkerConfiguration;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By moving it to SparkJobProps instead of leaving it to JobProps means this property will not be anymore in PythonShellJobProps, is that intended?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but PythonShellJobProps never reads them. What controls its capacity is maxCapacity.

* configuration requires both values, so a Spark job can never be given one
* without the other.
*/
export interface WorkerConfiguration {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm always confused when nesting vs flat for me this against guideline, can you explain to me why did you go with this choice and also update the guideline for other to understand?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By default, we should prefer flat interfaces, to make it more ergonomic for other jsii languages, such as Java. So, if it's just to organize the fields more nicely, it's not worth it. But here, the nested interface serves another ergonomic purpose: to make sure that invalid states are unrepresentable. In this case, workerType and numberOfWorkers must either both be set or neither. If they are two independent optional props in a flat interface, nothing prevents you from setting one and not the other. If they are required properties in a nested interface, you can't do that.

@aws-cdk-automation aws-cdk-automation added the pr/needs-maintainer-review This PR needs a review from a Core Team Member label Aug 17, 2026
@mergify

mergify Bot commented Aug 17, 2026

Copy link
Copy Markdown
Contributor

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

@mergify

mergify Bot commented Aug 17, 2026

Copy link
Copy Markdown
Contributor

Merge Queue Status

  • Entered queue2026-08-17 13:30 UTC · Rule: default-squash · triggered by rule automatic merge
  • Checks failed · in-place
  • 🚫 Left the queue2026-08-17 13:34 UTC · at c81143f42016d77419d4751fa7ee03598cfde4c9

This pull request spent 3 minutes 59 seconds in the queue, with no time running CI.

Waiting for
  • any of: [🛡 GitHub branch protection]
    • check-neutral = validate-pr
    • check-skipped = validate-pr
    • check-success = validate-pr
  • any of: [🛡 GitHub branch protection]
    • check-neutral = build
    • check-skipped = build
    • check-success = build
All conditions

Reason

The merge conditions cannot be satisfied due to failing checks

Failing checks:

Hint

You may have to fix your CI before adding the pull request to the queue again.
If you update this pull request, to fix the CI, it will automatically be requeued once the queue conditions match again.
If you think this was a flaky issue instead, you can requeue the pull request, without updating it, by posting a @mergifyio queue comment.

Tick the box to put this pull request back in the merge queue (same as @mergifyio queue).

  • Requeue this pull request

@mergify
mergify Bot deployed to automation August 17, 2026 13:30 Active
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

contribution/core This is a PR that came from AWS. p2 pr/needs-maintainer-review This PR needs a review from a Core Team Member pr-linter/exempt-integ-test The PR linter will not require integ test changes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants