ferruzzi commented on code in PR #37786:
URL: https://github.com/apache/airflow/pull/37786#discussion_r1508010742
##########
tests/providers/amazon/aws/executors/ecs/test_ecs_executor.py:
##########
@@ -829,6 +830,45 @@ def test_update_running_tasks_failed(self, mock_executor,
caplog):
"test failure" in caplog.messages[0]
)
+ def test_try_adopt_task_instances(self, mock_executor):
+ """Test that executor can adopt orphaned task instances from a
SchedulerJob shutdown event."""
+ mock_executor.ecs.describe_tasks.return_value = {
+ "tasks": [
+ {
+ "taskArn": "001",
Review Comment:
I'm not 100% confident with k8s but I believe the answer to your question is
yes, they are serving the same functional purpose here?
A task ARN is essentially the UUID (or maybe a URI is more accurate)
assigned to the task by the ECS cluster when it launches the task. In reality,
the value here is going to be in the format
`arn:aws:{service_name}:{region}:{account_number}:task/{cluster_name}/{task_uuid}`,
so something like
`arn:aws:ecs:us-east-1:8675309:task/ecs-executor-cluster/4d080c8e273f4d47af3037793084f6a8`.
For the purpose of the test, the exact format is irrelevant so I used 001 to
make it easier to read.
In the task adoption code, we are using that ARN as the external_executor_id
because it is a globally unique value and that is how we can re-connect to
that particular task to monitor it.
--
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]
