Zum Inhalt

Polycrate API 0.18.0

Release-Datum: 29. Mai 2026
Typ: Feature

Highlights

  • Dashboard Cockpit-Redesign – Workspace- und Organization-Dashboard wurden grundlegend überarbeitet: 4-Kachel-Layout, Maintenance-Übersicht, Timeslots, letzte Downtimes und Backup-Schedule-Status auf einen Blick.
  • Maintenance-Management via Managed Object Dashboard – Maintenance und MaintenanceWindow wurden vollständig auf das Managed Object Dashboard migriert inkl. Time Slots Widget, Breadcrumb Fix und aktivem Maintenance-Header-Label.
  • Criticality-Vererbung – Kritikalitätsstufen werden jetzt automatisch entlang der Objekthierarchie vererbt: Organization → Workspace → ManagedObject.
  • Backup-VerbesserungenBACKUP_FAILED-Condition in save(), BackupSchedule Overdue-Condition, überarbeitete Detail-UI, Workspace K8s Backup Bucket Create-Flag & Edit-Select.

Details zu einzelnen Specs: polycrate spec inspect <id> im Workspace polycrate-api.

Artefakte

Docker Image

docker pull cargo.ayedo.cloud/polycrate/polycrate-api:0.18.0

Block

polycrate pull cargo.ayedo.cloud/ayedo/k8s/polycrate-api
polycrate run polycrate-api install

Features

Dashboard Cockpit-Redesign

Das Workspace- und Organization-Dashboard wurden grundlegend überarbeitet:

  • Workspace Dashboard – Obere Sektion im Cockpit-Stil mit 4 Kacheln: aktive Maintenances mit Timeslots, Backup-Schedule-Status, letzte 5 Downtimes und freie vierte Kachel
  • Organization Dashboard – 4-Kachel-Cockpit-Block analog zum Workspace-Dashboard
  • Backup-Schedule-Kachel aus der alten Sektion in das neue Layout verschoben
  • Timeslots ersetzen Maintenance-Labels als primäre Darstellung im Dashboard

Maintenance-Management

  • Managed Object Dashboard Migration – Maintenance und MaintenanceWindow wurden vollständig migriert
  • Time Slots Widget – Neue UI-Komponente zur Darstellung von Wartungsfenstern
  • Aktiver Maintenance-Header – Workspace-Topbar zeigt Label wenn aktive Maintenance vorliegt
  • DataSource Create/Edit – Breadcrumb Fix und create_maintenance_as_draft-Unterstützung

Criticality-Vererbung

Kritikalitätsstufen werden automatisch entlang der Objekthierarchie propagiert:

  • Organization → Workspace → ManagedObject
  • Fehlende Criticality auf untergeordneten Objekten wird vom übergeordneten Objekt übernommen
  • Ermöglicht org-weite Criticality-Policies ohne manuelle Einzel-Konfiguration

Backup-Verbesserungen

  • BACKUP_FAILED Condition – Wird direkt in save() gesetzt wenn ein Backup fehlschlägt
  • BackupSchedule Overdue Workspace-Condition – Workspace erhält Condition wenn BackupSchedule überfällig ist
  • Backup Schedule Detail UI – Überarbeitete Detail-Ansicht mit korrekter Total-Backup-Anzeige
  • Workspace K8s Backup Bucket – Create-Flag und Edit-Select für zugewiesenen Backup-Bucket

Notes & Editor

  • Context-Aware Notes-Scoping – Notes-Tab in Workspace und Organization zeigt nur kontextrelevante Notes
  • TipTap Hyperlink-Unterstützung – Hyperlinks können im Note-Editor erstellt und bearbeitet werden
  • Reply-Datum wählbar – Bei Projekt-Notes (Time Tracking) kann das Datum für Replies manuell gesetzt werden

Status-Label & UI

  • Zentrales Status-Label Templatetag – Einheitliches Templatetag für Statusanzeigen mit Client-Side-Parität
  • S3Cluster Table – Used Storage und Backend Usage Bar direkt in der Listenansicht sichtbar
  • GrafanaDashboard-Feature entfernt – Veraltete Grafana-Dashboard-Integration wurde entfernt

Fixes

  • ActionRun FAILED Condition setzt state nicht mehr fälschlicherweise auf CRITICAL
  • BlockRollout BLOCKED-Status setzt jetzt korrekt eine WARNING-Condition
  • BlockRolloutItem Items-Tabelle zeigt Target Version an
  • S3Bucket Encryption/Versioning-Buttons erst nach abgeschlossener Reconciliation sichtbar
  • Backup Schedule Detail – Total Backups zählt korrekt
  • Note Content Importyjs_state Seeding-Bedingung mit korrekter fragment.length-Prüfung
  • nginx ingressproxy-request-buffering deaktiviert (verhinderte dass Client-Body auf Disk gebuffert wurde)

Kompatibilität und Deployment

  • Enthält Datenbankmigrationen — Migration vor dem Deployment ausführen.
  • Kein Breaking Change für bestehende API-Clients.