boring-cyborg[bot]
commented
1 month ago Thanks for opening your first issue here! Be sure to follow the issue template! If you are willing to raise PR to address this issue please do so, no need to wait for approval.
Ajit-mycom
Official Helm Chart version
1.13.1
Apache Airflow version
2.8.1
Kubernetes Version
1.29
Helm Chart configuration
No response
Docker Image customizations
No response
What happened
I have deployed Apache Airflow with the multiNamespaceMode: true setting, which resulted in the creation of a ClusterRole with
permissions limited to pods only. However, I need to add permissions for sparkapplications in the API group sparkoperator.k8s.io
because I am encountering the following error:
cannot create resource "sparkapplications" in API group "sparkoperator.k8s.io"
I explored two potential solutions:
Manual Role Editing: I found that manually editing or patching the ClusterRole is not permitted, which does not provide a
sustainable solution.
Local Chart Modification: While modifying the ClusterRole in a local Airflow chart could resolve the issue, it introduces complexity
as it necessitates using a custom chart for upgrades and feature management.
Given these constraints, I am seeking guidance from the Airflow team on how to address this issue. Is there an alternative
approach to manage sparkapplications permissions within the current deployment setup? Your assistance would be greatly
appreciated.
What you think should happen instead
there must be clusterrole and clusterrolebinding for sparkapplications currently we have only for pods which works with multinamespace = true
How to reproduce
I have deployed Apache Airflow with the multiNamespaceMode: true setting, which resulted in the creation of a ClusterRole with
permissions limited to pods only. However, I need to add permissions for sparkapplications in the API group sparkoperator.k8s.io
because I am encountering the following error:
cannot create resource "sparkapplications" in API group "sparkoperator.k8s.io"
I explored two potential solutions:
Manual Role Editing: I found that manually editing or patching the ClusterRole is not permitted, which does not provide a
sustainable solution.
Local Chart Modification: While modifying the ClusterRole in a local Airflow chart could resolve the issue, it introduces complexity
as it necessitates using a custom chart for upgrades and feature management.
Given these constraints, I am seeking guidance from the Airflow team on how to address this issue. Is there an alternative
approach to manage sparkapplications permissions within the current deployment setup? Your assistance would be greatly
appreciated.
Anything else
No
Are you willing to submit PR?
Code of Conduct