<p>I am working on Airflow 1.10.</p>
<p>I have problem with running commands on KubernetesPodOperator, where entire command is evaluated during DAG runtime.</p>
<p>I am generating command in DAG runtime as some of command's arguments depends on parameters passed by user.</p>
<p>As I read from documentation
KubernetesPodOperator expects list of strings or list of jinja templates:</p>
<pre><code>    :param arguments: arguments of the entrypoint. (templated)
        The docker image's CMD is used if this is not provided.
</code></pre>
<p>I have PythonOperator which generates command and push it to XCOM and KubernetesPodOperator
where in arguments I pass command generated by PythonOperator.</p>
<pre><code>from airflow.operators.python_operator import PythonOperator
from airflow.contrib.operators.kubernetes_pod_operator import KubernetesPodOperator


def command_maker():
    import random # random is to illustrate that we don't know arguments value before runtime
    return f&quot;my_command {random.randint(1, 10)} --option {random.randint(1, 4)}&quot;

def create_tasks(dag):
    first = PythonOperator(
        task_id=&quot;generate_command&quot;,
        python_callable=command_maker,
        provide_context=True,
        dag=dag,
    )
    second = KubernetesPodOperator(
        namespace='some_namespace',
        image='some_image',
        name='execute_command',
        dag=dag,
        arguments=[f'{{ ti.xcom_pull(dag_id=&quot;{dag.dag_id}&quot;, task_ids=&quot;generate_command&quot;, key=&quot;return_value&quot;)}}']
    )
    second.set_upstream(first)
</code></pre>
<p>Unfortunately KubernetesPodOperator doesn't run this command correctly as he tries to run something like this:</p>
<pre><code>[my_command 4 --option 2]
</code></pre>
<p>Is there way to eval this list at KubernetesPodOperator runtime
or am I enforced to push all runtime arguments into separate XCOM's?
I would like to avoid such solution as it required lot of changes in my project.</p>
<pre><code>         arguments=[
            &quot;my_command&quot;,
            f'{{ ti.xcom_pull(dag_id=&quot;{dag.dag_id}&quot;, task_ids=&quot;generate_command&quot;, key=&quot;first_argument&quot;)}}',
            &quot;--option&quot;,
            f'{{ ti.xcom_pull(dag_id=&quot;{dag.dag_id}&quot;, task_ids=&quot;generate_command&quot;, key=&quot;second_argument&quot;)}}',
         ]
</code></pre>

domandinho
<p>The problem is that JINJA template returns the template as string by default.</p>
<p>In recent Airflow, however (As of Airlfow 2.1.0)  you can render the templates as native python objects:</p>
<p><a href="https://airflow.apache.org/docs/apache-airflow/stable/concepts/operators.html#rendering-fields-as-native-python-objects" rel="nofollow noreferrer">https://airflow.apache.org/docs/apache-airflow/stable/concepts/operators.html#rendering-fields-as-native-python-objects</a></p>
<p>By using a <code>render_template_as_native_obj=True</code> parameter when you create DAG.</p>
<p>Then you need to format your output in the way that python's <code>literal_eval</code> will be able to convert it to python object. In your case you have to make the output similar to:</p>
<p><code>[ 'my_command', '4', '--option', '2' ]</code></p>
<p>Note that this parameter will return native objects for all your templates so if they return some values that <a href="https://jinja.palletsprojects.com/en/2.11.x/nativetypes/" rel="nofollow noreferrer">literal_eval understands</a> - they will also be converted to native types (and you might have some unintended side-effects.</p>
