PoPs & Provider¶

Provider und Points of Presence (PoPs) bilden die physische/logische Infrastruktur-Landkarte in Polycrate ab. Sie beantworten die Fragen:

Wer betreibt eine Ressource? → Provider
Wo läuft eine Ressource? → PoP

Beide Modelle werden auf Plattform-Ebene gepflegt und sind für alle Organisationen sichtbar.

Provider¶

Ein Provider ist ein Katalog-Eintrag für ein Unternehmen, das Infrastruktur, Hardware oder Software liefert — z. B. Hetzner, AWS, OVH, Cisco, VMware. Provider sind keine Zugangsdaten und auch nicht pro Workspace definiert; sie sind eine stabile, systemweite Referenz.

Feld	Zweck
`name` / `display_name`	Anzeige-Name in der UI
`kind`	`infrastructure`, `hardware`, `software`
`logo`	Logo für Listen und Detailviews
`ccm_block` / `csi_block`	Optionaler Hinweis, welcher Polycrate-Block als Cloud-Controller-Manager bzw. CSI-Treiber zu diesem Provider passt
`website` / `status_page_url`	Verlinkung auf externe Ressourcen

Wofür Provider?

Konsistente Zuordnung — eine PoP in "Hetzner FSN1" zeigt denselben Provider-Eintrag wie eine andere PoP in "Hetzner NBG1".
Status-Integration — ein Provider kann mit einer DataSource verknüpft werden, die seine Statusseite als RSS-Feed importiert. Daraus entstehen automatisch Notes mit kind=provider-status.
Block-Empfehlung — wenn auf einem Cluster bei einem Provider ein CCM oder CSI-Treiber installiert werden soll, schlägt Polycrate anhand der ccm_block / csi_block-Felder einen passenden Block vor.

Nicht verwechseln mit Credentials

Ein Provider beschreibt wer, nicht wie man sich einloggt. Zugangsdaten laufen über separate Credentials (z. B. API-Tokens für Hetzner Cloud). Eine Credential kann auf einen Provider zeigen — muss aber nicht.

PoP (Point of Presence)¶

Ein PoP ist ein konkreter Standort: ein Rechenzentrum, eine Cloud-Region, ein Edge-Node. PoPs sind die Grundlage für Workspace-Platzierung, Latenzmessungen und Wartungsplanung.

Feld	Zweck
`name` / `display_name`	z. B. `hetzner-fsn1`, "Hetzner Falkenstein 1"
`kind`	`datacenter`, `region`, `edge`
`provider_entity`	FK auf Provider — muss gesetzt sein
`city`, `country`, `latitude`, `longitude`	Geo-Koordinaten für Karte und Routing
`endpoint_monitor`	Optional: ein Endpoint, der den PoP von außen prüft

Was ein PoP ermöglicht¶

Workspace-Platzierung: Ein Workspace kann einen bevorzugten PoP bekommen. Neue Ressourcen (K8s-Cluster, LoadBalancer, S3-Buckets) werden bei Neuanlagen vorgeschlagen, in diesem PoP zu liegen.
PoP-zu-PoP-Latenz: Wenn zwei PoPs Endpoint-Monitoring aktiv haben, erzeugt Polycrate die Metrik polycrate_latency_pop_to_pop_seconds mit Labels source_pop/target_pop. So entsteht eine Matrix aller Latenzen zwischen Präsenzen — hilfreich für Routing-Entscheidungen und Troubleshooting.
Wartungs-Scope: Eine Wartung kann auf einen PoP beschränkt werden. Alle Ressourcen in diesem PoP erscheinen damit automatisch im Wartungs-Scope, ohne dass sie einzeln ausgewählt werden müssen.
Karten-Darstellung: Das Dashboard zeigt alle PoPs als Pins auf einer Weltkarte, gefärbt nach aktuellem State (OK / WARNING / CRITICAL).

Beziehungen¶

┌──────────┐       ┌──────┐       ┌─────────────┐
│ Provider │◀──────│ PoP  │◀──────│  Workspace  │
└──────────┘       └──────┘       └─────────────┘
      ▲                ▲                  ▲
      │ optional FK    │ optional FK      │
      │                │                  │
┌──────────────┐   ┌──────────┐    ┌──────────────┐
│  DataSource  │   │ Wartung  │    │ K8s/S3/LB/…  │
│ (status-feed)│   │ (scope)  │    │  Ressourcen  │
└──────────────┘   └──────────┘    └──────────────┘

Jede PoP hat genau einen Provider.
Ein Provider kann viele PoPs haben.
DataSources können auf einen Provider zeigen (für Status-Feeds).
Wartungen können auf einen PoP zeigen (um ihren Scope zu beschränken).
Infrastruktur-Ressourcen (Cluster, LoadBalancer, S3, …) können optional eine PoP-Zuordnung tragen, um Geo-Kontext und Latenzen abzubilden.

Typischer Workflow¶

Provider anlegen — z. B. "Hetzner Cloud" als kind=infrastructure, mit Logo und Status-URL.
Status-DataSource (optional) — RSS-Feed der Hetzner-Statusseite als DataSource anlegen und mit dem Provider verknüpfen. Fortan landen Hetzner-Incidents automatisch als Notes im System.
PoPs anlegen — für jede Hetzner-Region (FSN1, NBG1, HEL1) je einen PoP mit Geo-Koordinaten.
Endpoint-Monitor pro PoP (optional, aber empfohlen) — erlaubt Latenz-Messungen und sichtbaren Gesundheitszustand auf der Karte.
Workspaces & Ressourcen — Workspaces/Ressourcen auf passende PoPs zeigen lassen, damit Dashboards, Wartungen und Latenz-Metriken korrekt gruppieren.

RBAC & Sichtbarkeit¶

Anlegen und Bearbeiten von Providern und PoPs ist Superuser-only, weil sie systemweit gelten. Alle authentifizierten Benutzer sehen die Einträge in Listen und Detailviews — die Information ist nicht sensitiv.