feat(stepfunctions-tasks): add executionRoleArn as EmrContainersStartJobRun prop #26926
Conversation
github-actions
bot
added
repeat-contributor
There was a problem hiding this comment.
The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.
msambol
changed the title
msambol
force-pushed
the
aws-stepfunctions-tasks-execution-role-arn
branch
from
184dffc
to
51a9499
Compare
aws-cdk-automation
dismissed
their stale review
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
aws-cdk-automation
added
the
pr/needs-community-review
| * The execution role arn for the job run. | ||
| * | ||
| * Used when both `virtualClusterId` and `executionRoleArn` need to be taken from a JSON input path. | ||
| * Conflicts with `executionRole` when both provided. `executionRole` takes precedence over `executionRoleArn`. |
There was a problem hiding this comment.
If both executionRole and executionRoleArn are set, please throw an error. This will help developers finding errors when both properties are set and the logic doesn't work as expected.
| private jobExecutionRoleFromArn(exectionRoleArn?: string): iam.IRole | undefined { | ||
| if (exectionRoleArn === undefined) { | ||
| return undefined; | ||
| } | ||
| return iam.Role.fromRoleArn(this, 'Job-Execution-Role-From-Arn', exectionRoleArn); | ||
| } |
There was a problem hiding this comment.
As I understand it, this PR is implemented to solve a problem with executionRole, because iam.Role can't be used here. In this code snippet, executionRoleArn is used to create an iam.Role again. Isn't it enough to note in the executionRole property that e.g. importedValues cannot be used? Do we really need this new property?
| virtualCluster: tasks.VirtualClusterInput.fromTaskInput(sfn.TaskInput.fromJsonPathAt('$.VirtualClusterId')), | ||
| releaseLabel: tasks.ReleaseLabel.EMR_6_2_0, | ||
| jobName: 'EMR-Containers-Job', | ||
| executionRoleArn: sfn.TaskInput.fromJsonPathAt('$.ExecutionRoleArn').value, |
There was a problem hiding this comment.
It's a mouthful, but wouldn't
executionRole: iam.Role.fromRoleArn(this, 'ExecRole', sfn.TaskInput.fromJsonPathAt('$.ExecutionRoleArn').value)Work here?
|
To elaborate, this PR works fine if you provide the actual ARN as a string for Code: Result: The same thing happens when trying this: |
|
Thanks @msambol ! This is unfortunate. 😕 Closing this PR for now. If you can take your questions back to the issue (or a new issue if it's sufficiently different) our triage team can have a look and maybe find a workaround with you. |
Adding an optional construct prop
executionRoleArnforEmrContainersStartJobRun.This allows the role ARN to be supplied as a string and thus taken from JSON input path.
One doubt: Should I throw an error if both
executionRoleandexecutionRoleArnare supplied?Or leave as-is and default to
executionRole?The integration test successfully deploys the stack but I had the damnedest time starting the state machine
because of EKS/k8s issues. Let me know if this is part of success criteria and I will spend more time on it.
Closes #21319.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license