MWAA Plugins and Dependency Survival Guide
Tags: airflow, bigdata, dataengineering, aws
Published: 2024-04-05 12:50:21

Very often it makes sense to use a managed service instead of undifferentiated heavy lifting of *properly* building and maintaining infrastructure.   For me, managing Apache Airflow definitely falls into this category and I often use AWS MWAA (Managed Workflows for Apache Airflow).

As many of you have worked with Airflow already know, customizations, especially modifications to the Python environment can be tricky, and in some cases dangerous.  This is mainly due to the fact that Airflow itself is a complex Python application with it's own environmental considerations and dependencies.  

This is why I continue to campaign that folks keep their Airflow environment small and purposeful, and reduce customizations by using tools like the [pod operator](https://airflow.apache.org/docs/apache-airflow-providers-cncf-kubernetes/stable/operators.html).  I detail much of this in my article [The Wrath of Unicron](https://dev.to/aws-heroes/the-wrath-of-unicron-when-airflow-gets-scary-27kg).

However it's very difficult to stay completely vanilla :icecream:, so here are a few tips when customizing the MWAA environment.

### Tip 0: Use MWAA Local Runner###

I won't go into great detail here, because the docs are quite good.  But you should absolutely be developing, and testing all changes leveraging [MWAA Local Runner](https://github.com/aws/aws-mwaa-local-runner).   It's very close to the real thing and you will avoid waiting for changes to propagate in the actual MWAA environment (my one complaint is 20-40 minutes for an environment update is kinda crazy).

### Tip 1: LOGGING!! ###

Before you start any customization, turn your logging up to 11.   

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dxmd3zb8o9rmz1mnaq90.png)

You will need all the detailed log entries, especially for the Scheduler.    If your MWAA environment is not recognizing your changes, or getting stuck in the updating state (crash loop), check the _requirements_ log entries.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/icjo0rl45gza9e1fu0eg.png)

### Tip 2: Constraints File ###

For the past several versions of Airflow, a public constraints file has been published and maintained.   This constraint file protects Airflows dependencies and makes sure that customizations do not break things.  

:warning: With MWAA, messing up dependencies can cause the before-mentioned crash loop, which can often last for hours :sob:.

A constraint statement pointing to this file must be referenced in the top of your requirements.txt and will look something like this.

`--constraint "https://raw.githubusercontent.com/apache/airflow/constraints-{Airflow-version}/constraints-{Python-version}.txt"
`
# *DO NOT OMIT THE CONSTRAINT STATEMENT!!!* #
 
..but if you can't make the default file work, see Tip 3 below :smiley:

### Tip 3: Unresolvable Conflicts ###

Unfortunately not all Python packages are well maintained or have tight locking to upstream dependency versions.   Over time, you can run into unresolvable conflicts between your packages and plugins, and the constraints file.    

The first recommendation - upgrade to the latest version of Airflow.  It's very likely the problems you are experiencing are resolved in the latest version.  If this is not an option, I suggest certifying and hosting your own version of the constraint file.  This will involve tweaking the package dependencies and making sure they are compatible with Airflow.  

This may not be a trivial process, but try your best not to comment lines, and absolutely do not remove the constraints statement all together.

### Tip 4: Troubleshooting Plugins ###

Maybe you did think you did everything right (per the [docs](https://docs.aws.amazon.com/mwaa/latest/userguide/configuring-dag-import-plugins.html)), your MWAA environment is booting, but your Plugins are not installing.

First, check your _requirements_ log entries and see if anything has failed during the install.   Note that in most cases the requirements install will do a complete rollback of package installs, not just the offenders.

If you don't see your package being installed make sure you referenced your package correctly in your requirements file.

`/usr/local/airflow/plugins/data_common_utils-0.2.8-py3-none-any.whl`

If all this looks correct, try creating a simple "plugin finder" DAG, and make sure your plugin has been copied to the hosted environment.

```python
from airflow.utils.dates import days_ago
from airflow import DAG
from airflow.operators.bash import BashOperator


dag =  DAG(dag_id = 'plugin-finder', start_date=days_ago(1))
    


ls_airflow_plugins = BashOperator(
    task_id="ls_airflow_plugins",
    bash_command="ls -laR /usr/local/airflow/plugins",
    dag=dag,
    priority_weight=300,
)
```

### Good Luck! ###

I hope you all find this helpful.  Please comment with other helpful tips!

[Data Futures](https://www.datafutures.io/)