You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We offer the customer to inject DAGs into airflow in two ways:
Customers can mount a configMap into the Airflow pod and store the DAGs there.
Customers can use GitSync to host DAGs in an git repository.
Both ways need a way to interact either with kubernetes itself or with git.
Proposed Situation
Customers can log into Airflow and edit DAGs in the Airflow UI.
To archive this, we'd need to include an editor in airflow dockerimage and make it configurable through the operators CRD. I'd propose https://github.com/andreax79/airflow-code-editor as an candidate.
Advantage
Now where #573 is merged, we offer deeply integrated Open Policy Agent support, which would lead to the advantage to offer role based editor access to data engineers or product owners. There wouldn't be a need to have knowledge of kuberentes or git to modify, develop and deploy DAGs. In my opinion this would increase usability and accessibility of Airflow and could empower the customer.
Additionally, it would make the development process of DAGs much easier as we would move from develop -> deploy -> test to develop -> test.
Evaluation
I expect this to be a rather large feature. We'd need to think about roles and how to configure those for editor access without OPA too. We need to be able to integrate with GitSync and implement access, provisioning and usage of PVCs to store DAGs written in the Airflow UI. Role based access may also apply to files stored in PVCs. We introduce at least another dependency we might need to maintain.
The text was updated successfully, but these errors were encountered:
Current Situation
We offer the customer to inject
DAGs
into airflow in two ways:configMap
into the Airflow pod and store theDAGs
there.DAGs
in an git repository.Both ways need a way to interact either with kubernetes itself or with git.
Proposed Situation
Customers can log into Airflow and edit
DAGs
in the Airflow UI.To archive this, we'd need to include an editor in airflow dockerimage and make it configurable through the operators CRD. I'd propose https://github.com/andreax79/airflow-code-editor as an candidate.
Advantage
Now where #573 is merged, we offer deeply integrated
Open Policy Agent
support, which would lead to the advantage to offer role based editor access to data engineers or product owners. There wouldn't be a need to have knowledge of kuberentes or git to modify, develop and deployDAGs
. In my opinion this would increase usability and accessibility of Airflow and could empower the customer.Additionally, it would make the development process of
DAGs
much easier as we would move from develop -> deploy -> test to develop -> test.Evaluation
I expect this to be a rather large feature. We'd need to think about roles and how to configure those for editor access without
OPA
too. We need to be able to integrate with GitSync and implement access, provisioning and usage of PVCs to storeDAGs
written in the Airflow UI. Role based access may also apply to files stored in PVCs. We introduce at least another dependency we might need to maintain.The text was updated successfully, but these errors were encountered: