apache/airflow

Launch Pod/job in separate namespace and support in helm chart

Open

#25 222 ouverte le 21 juil. 2022

Voir sur GitHub
 (6 commentaires) (1 réaction) (0 assignés)Python (16 781 forks)batch import
area:helm-chartgood first issuekind:feature

Métriques du dépôt

Stars
 (44 809 stars)
Métriques de merge PR
 (Merge moyen 7j 18h) (834 PRs mergées en 30 j)

Description

Description

Our engineers want to run jobs in a separate namespace from the installed release via helm chart.

It looks to me like right now the rbac configuration has two choices

  • multicluster - generates ClusterRole
  • !multicluster - generales rolebinding in RELEASE namespace.

Why these don't work for us

  • multicluster is too wide, we want to restrict the namespace
  • !multicluster - I think only lets stuff be generated in the same namespace? Or will airflow be able to generate pods in another namespace

Sorry for the ignorant questions - don't really know airflow, just trying to help out the engineers.

Use case/motivation

Our engineers want to run jobs in a separate namespace from the installed release via helm chart.

Related issues

There are some about pod override of namespace, I'm not sure due to inexperience with Airflow

Are you willing to submit a PR?

  • Yes I am willing to submit a PR!

Code of Conduct

Guide contributeur

Direction de recherche
Étudiez la configuration RBAC du chart Helm d'Airflow, en particulier les conditions pour multicluster vs non multicluster. Identifiez où les références de namespace sont codées en dur et proposez un mécanisme pour permettre aux utilisateurs de spécifier un namespace séparé pour l'exécution des pods/jobs. Examinez les issues et pull requests associés pour des travaux antérieurs. Assurez vous que la solution respecte les contraintes de sécurité et n'accorde pas de permissions excessives.
Stack technique
pythonkubernetesdocker
Domaine
devopsinfrastructure
Type d'issue
Fonctionnalité
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
3
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-2 jours
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Plutôt claire
Prérequis
GitKubernetesHelm
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
65