You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by GitBox <gi...@apache.org> on 2020/06/15 08:08:31 UTC

[GitHub] [airflow] evgenyshulman commented on a change in pull request #8651: [AIP-31] [AIRFLOW-8058] Retrieve current execution context without altering function's signature

evgenyshulman commented on a change in pull request #8651:
URL: https://github.com/apache/airflow/pull/8651#discussion_r440000032



##########
File path: docs/howto/use-additional-execute-contextmanager.rst
##########
@@ -0,0 +1,68 @@
+ .. Licensed to the Apache Software Foundation (ASF) under one
+    or more contributor license agreements.  See the NOTICE file
+    distributed with this work for additional information
+    regarding copyright ownership.  The ASF licenses this file
+    to you under the Apache License, Version 2.0 (the
+    "License"); you may not use this file except in compliance
+    with the License.  You may obtain a copy of the License at
+
+ ..   http://www.apache.org/licenses/LICENSE-2.0
+
+ .. Unless required by applicable law or agreed to in writing,
+    software distributed under the License is distributed on an
+    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+    KIND, either express or implied.  See the License for the
+    specific language governing permissions and limitations
+    under the License.
+
+
+
+Defining Additional Execute Context Manager
+===========================================
+
+Creating new context manager
+----------------------------
+
+Users can create their own execution context manager to allow context management on a higher level.
+To do so, one must define a new context manager in one of their files. This context manager is entered
+before calling ``execute`` method and is exited shortly after it. Here is an example context manager
+which provides authentication to Google Cloud Platform:
+
+    .. code-block:: python
+
+      import os
+      import subprocess
+      from contextlib import contextmanager
+      from tempfile import TemporaryDirectory
+      from unittest import mock
+      from google.auth.environment_vars import CLOUD_SDK_CONFIG_DIR
+      from airflow.providers.google.cloud.utils.credentials_provider import provide_gcp_conn_and_credentials
+
+      def execute_cmd(cmd):
+          with open(os.devnull, 'w') as dev_null:
+            return subprocess.call(args=cmd, stdout=dev_null, stderr=subprocess.STDOUT)
+
+      @contextmanager
+      def provide_gcp_context(task_instance, execution_context):

Review comment:
       > @evgenyshulman My solution allows for two use cases - task context, global context) Your proposal allows you to complete only one use case - global context. Is there any reason to keep this context as a global option? Did I miss something? I am not sure which solution is the best and I would like to understand both solutions.
   
   I am in favor of keeping the solution simple. The only concern is that current policy implementation requires airflow_local_settings that I don't see in use by most of the airflow cases. also in our use case, we need it on a global level so this is why we have done it this way. Do you see that you'll use it as a policy right after we implement it via policy? 




----------------------------------------------------------------
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.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org