ramitkataria commented on code in PR #71207:
URL: https://github.com/apache/airflow/pull/71207#discussion_r3732874337
##########
providers/amazon/tests/system/amazon/aws/example_emr_eks.py:
##########
@@ -385,15 +334,15 @@ def delete_virtual_cluster(virtual_cluster_id):
create_cluster_and_nodegroup,
await_create_nodegroup,
run_eksctl_commands(eks_cluster_name, eks_namespace),
- update_trust_policy_execution_role(eks_cluster_name, eks_namespace,
job_role_name),
- wait_for_trust_policy_propagation(eks_cluster_name, job_role_name),
+ install_pod_identity_agent(eks_cluster_name),
+ create_pod_identity_role_associations(eks_cluster_name, eks_namespace,
job_role_name),
Review Comment:
There's nothing documented about it and I didn't run into it in my testing.
There's also a lot of natural slack: the associations are created before
create_emr_eks_cluster, then StartJobRun, then EMR has to schedule the pod and
pull the image. That adds up to a few minutes, which should be plenty. And
job_starter already has retries=2 with a 2-minute delay as a backstop.
I tried a readback poll on list_pod_identity_associations and dropped it
because if the CLI exits 0 the associations are already there, so it was just
re-reading a deterministic result, and it wouldn't prove the agent can actually
vend credentials anyway. Only the job running shows that.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
