apache/airflow

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

Open

#25.222 geöffnet am 21. Juli 2022

Auf GitHub ansehen
 (6 Kommentare) (1 Reaktion) (0 zugewiesene Personen)Python (16.781 Forks)batch import
area:helm-chartgood first issuekind:feature

Repository-Metriken

Stars
 (44.809 Stars)
PR-Merge-Metriken
 (Durchschn. Merge 7T 18h) (834 gemergte PRs in 30 T)

Beschreibung

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

Contributor Guide

Research-Richtung
Untersuche die RBAC Konfiguration des Airflow Helm Charts, insbesondere die Bedingungen für Multicluster vs. Nicht Multicluster. Identifiziere, wo Namespace Referenzen fest codiert sind, und schlage einen Mechanismus vor, der es Benutzern ermöglicht, einen separaten Namespace für die Pod/Job Ausführung anzugeben. Überprüfe verwandte Issues und Pull Requests auf Vorarbeiten. Stelle sicher, dass die Lösung Sicherheitsbeschränkungen einhält und keine übermäßigen Berechtigungen gewährt.
Tech Stack
pythonkubernetesdocker
Domain
devopsinfrastructure
Issue Type
Funktion
SchwierigkeitGeschätzte Implementierungsschwierigkeit für neue Contributors, von 1 für sehr kleine Änderungen bis 5 für Expertenarbeit.
3
Geschätzte ZeitEin grober Zeitrahmen, um zu recherchieren, zu implementieren, zu testen und einen Pull Request vorzubereiten.
1-2 Tage
AktivitätsstatusWie verfügbar das Issue gerade wirkt: frisch, aktiv, stale, blockiert oder wartet auf Maintainer-Input.
Aktiv
KlarheitWie klar das Issue die erwartete Änderung, Akzeptanzkriterien und den nächsten Schritt erklärt.
Meist klar
Voraussetzungen
GitKubernetesHelm
EinsteigerfreundlichkeitEin Score von 1 bis 100, der schätzt, wie zugänglich dieses Issue für First-Time Contributors ist.
65