[GitHub] jj-ian commented on a change in pull request #4083: [AIRFLOW-3211] Reattach to GCP Dataproc jobs upon Airflow restart

[GitBox <gi...@apache.org>]

jj-ian commented on a change in pull request #4083: [AIRFLOW-3211] Reattach to GCP Dataproc jobs upon Airflow restart 
URL: https://github.com/apache/incubator-airflow/pull/4083#discussion_r239595197
 
 

 ##########
 File path: airflow/contrib/hooks/gcp_dataproc_hook.py
 ##########
 @@ -33,12 +33,82 @@ def __init__(self, dataproc_api, project_id, job, region='global',
         self.dataproc_api = dataproc_api
         self.project_id = project_id
         self.region = region
+
+        # Check if the job to submit is already running on the cluster.
+        # If so, don't resubmit the job.
+        try:
+            cluster_name = job['job']['placement']['clusterName']
+        except KeyError:
+            self.log.error('Job to submit is incorrectly configured.')
+            raise
+
+        jobs_on_cluster_response = dataproc_api.projects().regions().jobs().list(
+            projectId=self.project_id,
+            region=self.region,
+            clusterName=cluster_name).execute()
+
+        UUID_LENGTH = 9
 
 Review comment:
   Hi @fenglu-g , I started working on the regex idea and I don't think it makes sense to have the user define the deduping logic. 
   
   It seems more error prone to me to have the user define the job ID they want to use for deduping, since the job ID is not user defined, but is instead hardcoded by Airflow here as the task ID + first 8 characters of UUID: https://github.com/apache/incubator-airflow/blob/0e8394fd23d067b7e226c011bb1825ff734219c5/airflow/contrib/hooks/gcp_dataproc_hook.py#L94. Since Airflow sets the job ID, Airflow should also set the deduping logic.
   
   I understand your concern about not wanting to hardcode the deduping logic, though. A solution for this could be: instead of having Airflow hardcode the job ID as in the link above, to have it instead call a function that creates the job ID from the task ID. And then my deduping logic would reference an inverse of that function to extract the task ID for deduping instead of hardcoding the deduping logic. 
   
   In other words, Airflow would create the job ID with a function that maps the task ID -> job ID. And then the dedupe mechanism would call a function that maps from job ID back to task ID to use in deduping. Tests will be added to make sure that these two functions are inverses of each other. 
   
   How does that sound?

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services